Cosmos Conf 2026: AI Çağında Veritabanı Mimarisi Nereye Gidiyor?

⏱️ 11 dk okuma📅 12 Mayıs 2026🔄 Güncelleme: 15 Temmuz 2026👁️ görüntülenme

Geçen hafta Cosmos Conf 2026 oturumlarını izlerken önümde bir not defteri vardı. Yarım saat bile geçmeden sayfalar doldu (buna dikkat edin). Açık konuşayım, içerik yoğun olur diye bekliyordum; ama bu kadar net bir yön değişimi göreceğimi sanmıyordum.

📋 İçindekiler

Bir de şunu söyledi: binlerce geliştirici aynı anda iterate ediyor, ürün geliştiriyor. Bu insanları veritabanına onboard etmenin kolay olması lazım. Burada durup düşündüm biraz. Türkiye’de kurumsal yapılarda — özellikle bankacılık ve telkoda — bir geliştiricinin yeni bir veritabanına onboard olması haftalar sürebiliyor; onboarding değil, resmen küçük bir göç operasyonu gibi ilerliyor. Sız ne dersiniz? Evet.

Peki Türkiye’deki Şirketler İçin Bu Ne Anlama Geliyor?

Bu kısım önemli, boş geçmeyelim. Çünkü konferanstaki konuşmacıların çoğu Silikon Vadisi tarafında yaşıyor, bizim tarafta işe iş biraz başka akıyor; açık konuşayım, burada karar verirken sadece teknolojiye değil, ekip alışkanlığına ve mevcut sistemin inadıyla da uğraşıyorsunuz.

Kurumsal yapılarda direnç hâlâ var

Logosoft’ta geçen yıl bir sigorta şirketiyle çalıştık. Onlara document database ve vektör arama önerdiğimde ilk tepki şu öldü: “Biz SQL Server’la 15 yıldır iyi gidiyoruz, niye değiştirelim?” Haklılar bir açıdan, çünkü çalışan sistemi durduk yere bozmak istemezsiniz; ama mesele sistemi yıkmak değil, yeni iş yükleri için doğru aleti seçmek, yanı bazen eski düzen yerinde kalıyor ama yanına başka bir parça eklemek gerekiyor.

Senaryo	Önerilen Yaklaşım	Yaklaşık Maliyet Profili
RAG tabanlı dahili chatbot (orta ölçek)	Cosmos DB NoSQL + DiskANN vektör	Aylık 200-800 USD
Büyük ölçekli müşteri ajanı (milyonlarca query)	Cosmos DB provisioned + autoscale + integrated cache	Aylık 2.000+ USD
Prototip / hackathon	Serverless tier	Aylık 5-50 USD
Hibrit — kayıt SQL’de, vektör Cosmos’ta	Azure SQL + Cosmos DB	Değişken, mimariye bağlı

İşte tam da bu noktada devreye giriyor.

Bu arada SQL Server tarafında da hava değişiyor.

Pratik Karşılaştırma: Hangi Senaryoda Ne Kullanılır?

Ne yalan söyleyeyim, Burada bir tablo iyi gidiyor, çünkü lafı uzatınca konu dağılıyor. Sahada gördüğüm senaryolara bakınca kabaca böyle ayırıyorum; hani işin içinde hem maliyet var hem de mimarı kararlar var, o yüzden tek cümleyle geçmek pek olmuyor.

Senaryo Önerilen Yaklaşım Yaklaşık Maliyet Profili

RAG tabanlı dahili chatbot (orta ölçek) Cosmos DB NoSQL + DiskANN vektör Aylık 200-800 USD

Büyük ölçekli müşteri ajanı (milyonlarca query) Cosmos DB provisioned + autoscale + integrated cache Aylık 2.000+ USD

Prototip / hackathon Serverless tier Aylık 5-50 USD

Hibrit — kayıt SQL’de, vektör Cosmos’ta Azure SQL + Cosmos DB Değişken, mimariye bağlı

Bu rakamlar yaklaşık, yanı nokta atışı diye bakmayın. Asıl oyun RU/s tarafında dönüyor, bir de veri büyüklüğü devreye girince tablo biraz kayıyor; hatta bazen ilk baktığınız rakamla sahadaki gerçek maliyet arasında epey fark çıkıyor.

Evet.

Neyse, bir de şunu özellikle söylüyorum: kuruda hesap yapmayın. Türkiye’deki müşterilerde bunu defalarca gördüm; önce gerçek workload’u en az 2 hafta ölçün, sonra reserved capacity alın, yoksa kağıt üstünde ucuz görünen şey pratikte can sıkabiliyor.

Peki neden?

Çünkü trafik deseniniz, sorgu sıklığınız ve veri dağılımınız netleşmeden verilen kapasite kararı çoğu zaman havada kalıyor. Açık konuşayım, bazen küçük bir optimizasyon bile faturayı aşağı çekiyor; bazen de “idare eder” dediğiniz yapı beklenmedik şekilde pahalıya patlıyor.

Eh, Tam da öyle.

Bir de Şu Var: Agent-Friendly Veritabanı Ne Demek?

Bi saniye — Bu kavram konferansta epey dolaştı, ama açık konuşayım, herkes aynı netlikte anlatmadı. Ben kendi kafamdaki hâliyle toparlayayım.

Bir AI ajanı veritabanıyla konuşurken bizim gibi ilerlemiyor. SQL yazmıyor, en azından çoğu senaryoda öyle; onun yerine “Bana son 30 günde X kategorisinden satış yapan ve memnuniyet skoru 4 üzeri olan müşterileri getir” gibi bir şey söylüyor, sonra da bu cümleyi alıp sorguya çevirmek gerekiyor.

İşte burada Azure Cosmos DB Shell Public Preview: CLI’a AI Geldi yazımda anlattığım Cosmos Shell devreye giriyor (evet, doğru duydunuz). Doğal dili alıyor, NoSQL sorgusuna çeviriyor; ilk duyduğumda biraz “fazla iddialı” gelmişti,. Bir hafta kurcalayınca eski CLI’ya dönmek insanın içinden pek gelmiyor.

💡 Bilgi: Agent-friendly arayüzler sadece CLI ile sınırlı değil. MCP (Model Context Protocol) üzerinden veritabanına bağlanan ajanlar, schema discovery, query optimization gibi işleri otomatik yapabiliyor. Bu tarafta Microsoft Agent Framework tarafında da ciddi bir yatırım var.

Benim Eleştirim: Henüz Olgunlaşmamış Tarafları

Bence, Açık konuşayım, işin rengi o kadar da pembe değil. Konferansta pek dillendirilmeyen ama sahada insanın önüne çıkan birkaç can sıkıcı nokta var, hani şöyle ilk bakışta ufak duruyorlar ama sonra maliyet, bakım. Bu ne anlama geliyor? Operasyon tarafında başınızı ağrıtıyorlar.

Durun, bir saniye.

Maliyet öngörülebilirliği: RU/s modeli fena değil ama AI iş yüklerinde işi hesaplamak hâlâ zor. Bir embedding query’si bazen 5 RU yiyor, bazen 50 RU’ya fırlıyor — tamamen query plan’a göre değişiyor.
Vektör index reorganization: Embedding modelinizi değiştirdiğinizde — ki bu arada bu olay sandığınızdan daha sık oluyor — vektör index’i yeniden inşa etmek hâlâ uğraştırıyor. Microsoft bu tarafa çalışıyor, evet, ama şu an için “tamamdır” diyebileceğim bir çözüm yok.
Türkçe tokenization: Full-text search Türkçe diline pek iyi oturmuyor. Kök bulma zayıf kalıyor, ek ayırma da öyle. Eğer Türkçe içerikle çalışıyorsanız, bence external bir tokenizer ile metni hazırlayıp sonra Cosmos’a yazmak daha mantıklı.

İtiraf edeyim, Bu son maddeyi özellikle kenara koymak lazım (yanlış duymadınız) (eh, fena değil). Türkiye’deki bir e-ticaret müşterimizde “ayakkabı” ile “ayakkabılar” farklı dökümanlar gibi işleniyordu; garip geldi bana, çünkü kullanıcı gözünde aynı kökün etrafında dönüp duran kelimeler bunlar. Çözümü external preprocessing ile hallettik, iş görüyor. Cosmos’un kendi tarafındaki native Türkçe desteği hâlâ biraz ham, hatta açık söyleyeyim epeyce ham.

Hibrit Mimarı: Sahada En Çok Çalışan Model

Şunu söyleyeyim, Konferansta tek-veritabani romantizmi vardı biraz. Yanı “her şeyi Cosmos’ta tutun” havası. Gerçek hayatta o kadar düz gitmiyor, açık konuşayım. Benim son 18 ayda kurduğum AI uygulamalarının çoğu hibrit:

Islemsel veri ve compliance kayıtları -> Azure SQL veya PostgreSQL
Vektör embeddings ve RAG context -> Cosmos DB
Conversation memory ve session state -> Cosmos DB veya Redis — bunu es geçmeyin
Audit log ve immutable kayıt -> Azure Storage (append blob) (bu kritik)

Eh, Bu yapı ilk bakışta biraz karmaşık gözükebilir. Hani insan “tek yerde toplasam daha rahat olmaz mi?” diye düşünüyor. Ama dur bir saniye — her aracı doğru is için kullanınca maliyet %30-40 dusabiliyor, performans da idare eder seviyede kalmıyor, baya toparlıyor. Bir bankacılık projesinde tam olarak bu yaklaşımı uyguladık; fatura yarıya indi (bu beni çok şaşırttı)

İlk Adım Olarak Ne Yapmalısınız?

Diyelim ki bu yazıyı okudunuz ve “tamam, AI tarafında veritabanı seçimimi bir daha bakacağım” dediniz. Güzel. Ama burada durmayın; önce iş yüklerine bakın, sonra küçük bir deneme kurun, çünkü kağıt üstünde iyi duran şeyler gerçek trafikte bazen tökezliyor (özellikle RAG ve ajan senaryolarında), ben bunu birkaç kez gördüm.

Mevcut iş yüklerinizi sınıflandırın: Hangileri yapısal, hangileri yarı-yapısal? RAG var mı? Ajan mimarisi planlanıyor mu? Şey, ilk iş bu. Çünkü veri tipi netleşmeden seçtiğiniz model biraz sallantıda kalıyor.
Bir POC kurun: 2 haftalık bir prototip, Cosmos DB serverless tier’da, gerçek veriyle. 50 dolar bütçeyle test edebilirsiniz. Az para gibi geliyor ama bazen en çok şeyi o gösteriyor; hani üretimde çıkacak sürprizleri erken yakalıyorsunuz.
Ölçün: Latency, RU tüketimi, query patterns. Tahmin yürütmeyin, ölçün. Kulağa basit geliyor, evet, ama çoğu ekip burada dağılır; bir bakmışsınız herkes fikrini söylüyor, sayı yok.
Production’a geçmeden önce reserved capacity hesabı yapın: 1 yıllık taahhütle %20-25 indirim alıyorsunuz. Bak şimdi, bu kısım sıkıcı gibi dürüyor ama faturada fark yaratıyor; özellikle yükünüz oturmuşsa baya iş görüyor.
Monitöring kurmadan production’a çıkmayın: Application Insights + Cosmos DB metrics + custom dashboard. Yoksa fatura sürprizi kaçınılmaz. Evet, tam da öyle; izleme yoksa neyi neden yediğinizi sonradan anlamaya çalışırsınız, o da pek keyifli olmaz.

Sıkça Sorulan Sorular

Cosmos DB AI uygulamaları için gerçekten en iyi seçenek mi?

Peki, bir şey dikkatimi çekti: Her zaman değil açıkçası. Veri yapınız katı katı ilişkiselsse ve AI iş yükleriniz daha çok analitik taraflıysa, Azure SQL + vektör desteği daha mantıklı olabilir. Cosmos DB asıl yarı-yapısal veri, yüksek ölçeklenebilirlik ve global dağıtım gerektiren senaryolarda parlıyor. Yanı önce probleminizi tanıyın, sonra aleti seçin.

Serverless tier production için yeterli mi?

Küçük ve orta ölçekli uygulamalar için kesinlikle evet. Ama saniyede 1.000 RU’nun üstüne çıkıyorsanız ya da sürekli yüksek throughput gerekiyorsa, provisioned modele geçmeniz şart. Bence en sağlıklı yaklaşım şu: prototipte serverless kullanın, production’da gerçek workload’u ölçtükten sonra karar verin.

DiskANN vektör index ne zaman tercih edilmeli?

Milyonlarca vektörle uğraşıyorsanız ve düşük latency sizin için kritikse DiskANN’i düşünmeyin bile, direkt kullanın. Daha küçük ölçeklerde, hani yüz binlerce dokümana kadar olan senaryolarda, klasik flat ya da quantized vektör index’leri de gayet iş görüyor. Tecrübeme göre asıl belirleyici olan hafıza/disk dengesi oluyor burada.

Türkiye’de Cosmos DB için region desteği nasıl?

İnanın, Şu an itibarıyla Türkiye’ye yakın region’lar erişilebilir durumda, mesela UAE North gibi bölgeler var. Ama tam anlamıyla yerel bir Cosmos DB region’ı henüz yok. Veri ikametgahı yanı data residency gereksiniminiz varsa, en yakın Avrupa region’larına, West Europe ya da North Europe’a yönelebilirsiniz. Bu konuyu merak ediyorsanız Azure’ın Avrupa Yatırımları: Egemen Bulut. AI Genişlemesi yazıma bir göz atın; egemen bulut meselesi tam da bununla bağlantılı.

RAG mimarisinde chunk boyutu ne olmalı?

Standart bir cevap yok bu sorunun aslında. Ama 500-1500 token arası genelde iyi sonuç veriyor. Çok kısa chunk’lar context kaybettiriyor, çok uzunlar da retrieval kalitesini aşağı çekiyor. Sahada gördüğüm sweet spot 800-1000 token civarı. Overlap için de %10-15 öneririm, bence bu aralık oldukça dengeli bir nokta.

Kaynaklar ve İleri Okuma

Garip gelecek ama, Build AI apps with Azure Cosmos DB: Key trends from Cosmos Conf 2026 (Microsoft Azure Blog)

Azure Cosmos DB Resmî Dokümantasyonu

Azure Cosmos DB Vector Search Dokümantasyonu

Aslında, Azure Cosmos DB DevBlogs

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102