Cosmos Conf 2026: AI Çağında Veritabanı Mimarisi Nereye Gidiyor?
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.
İşin özünü tek cümleyle söyleyeyim: AI artık ayrı bir iş yükü değil. Uygulamaların ve veri platformlarının nasıl kurulduğunu baştan sona etkileyen bir kuvvet hâline geldi, hatta Kirill Gavrylyuk açılışta üç temel kaymayı anlattıktan sonra sahneye çıkanlar — OpenAI tarafı da var, daha küçük startup’lar da — bu değişimi kendi örnekleriyle tekrar tekrar gösterdi. Bakın, peki neden önemli? Çünkü mesele sadece model eklemek değil, mimarinin kendisi değişiyor.
Şimdi ben size bunu birebir aktarmayacağım. Zaten Microsoft’un bloğunda düzgünce var. Ben burada Türkiye’de kurumsal müşterilerde gördüklerimle, yanı (belki yanılıyorum ama) biraz saha tozu da katarak anlatacağım; çünkü kağıt üstündeki hikâye başka, prod ortamındaki telaş bambaşka oluyor. Hazırsanız başlayalım.
Üç Büyük Kayma: Aslında Neyi Söylüyorlar?
Konferansın omurgasını üç başlıkta topladım. Esneklik, hız ve anlam. Kulağa sade geliyor, biliyorum; ama işin aslı biraz daha karışık, çünkü bu üçünü aynı anda tutturmadan modern bir AI uygulamasını ayakta tutmak pek kolay değil.
1. Esnek, yarı-yapılandırılmış veri artık temel taş
Klasik veritabanı tarafında büyüyenler için bu kısım ilk bakışta garip gelebiliyor. Hani yıllardır schema first diye düşünüyoruz ya, önce tabloyu kuruyoruz, sonra alanları açıyoruz, ardından index’i ekliyoruz; AI tarafında işe işler o kadar düzgün ilerlemiyor, çünkü prompt var, memory var, context var. Hepsi durmadan şekil değiştiriyor.
Geçen ay bir e-ticaret müşterisinde tam da buna çarptık. RAG tabanlı bir öneri ajanı kuruyorduk; ilk hafta chunk yapısı bir haldeydi, ikinci hafta metadata’ya üç alan daha girdi, üçüncü hafta embedding modeli değişti. Vektör boyutu da doğal olarak kaydı. Klasik relational şemayla gitseydik her sprint’te migration script yazıp duracaktık, açık konuşayım yorucu olurdu; bizi toparlayan şey JSON document modelinin esnekliği öldü (ki bu çoğu kişinin gözünden kaçıyor)
Kısa bir not düşeyim buraya.
Veritabanları artık sadece kayıt sistemleri değil. Akıl yürütme sistemleri hâline geliyorlar. Bu cümle bana toplantıdaki en çarpıcı laftı geldi.
Evet. Tam burada mesele değişiyor.
2. Geliştirme hızı patladı
Coding agent’lar, Copilot, otonom geliştirme araçları… Hepsi üst üste binince geliştiricinin ritmi baya değişti. Eskiden bir feature için iki hafta harcadığımız işi şimdi iki günde çıkarabiliyoruz; şaşırdım açıkçası, ama sahada durum gerçekten bu.
Bir şey dikkatimi çekti: Şey ama, küçük bir problem var: veritabanı tarafı bu tempoya yetişemiyorsa bütün hız bir yerde tıkanıyor. Strict schema’lar, manuel scaling işleri, — itiraz edebilirsiniz tabi — capacity planning derken akış yavaşlıyor; yanı kod tarafı koşuyor. Tahmin eder mısınız? Altyapı biraz geriden geliyor.
İşte burada Kirill’in altını çizdiği birkaç nokta devreye giriyor:
- Serverless form factor — sıfırdan ölçeklenebilen, sen uyurken bile masraf üretmeyen
- Anlık ve sınırsız genişleyebilirlik (bu kritik)
- Entegre caching — Redis’i ayrı bir servis olarak yönetmek istemiyorsanız
- Agent-friendly arayüzler (MCP gibi protokoller dahil)
Peki neden önemli? Çünkü hız sadece kod yazmakla gelmiyor; veri katmanı da aynı hızda nefes alabiliyorsa iş görüyor.
3. Semantic search artık birinci sınıf vatandaş
Vektör arama, full-text arama, hybrid arama, semantic ranking… Bunlar eskiden “şu eklentiyi de kuralım” diye kenara atılan şeylerdi. Şimdi işe uygulamanın göbeğinde duruyorlar; retrieval olmadan AI uygulaması olmuyor, hybrid search olmadan da ciddi bir RAG kurulumu biraz eksik kalıyor.
Şimdi gelelim işin can alıcı noktasına.
Bunu daha derin işleyen bir yazıyı daha önce paylaşmıştım; Azure Cosmos DB ile Kurumsal Yapay Zekâ: Ölçek Meselesi başlıklı yazıya göz atabilirsiniz. Oradaki ölçek tartışmasıyla bu konferanstaki tema neredeyse birebir örtüşüyor; hatta bazı yerlerde aynı sorunun farklı cümlelerle tekrarlandığını bile düşündüm.
Şunu söyleyeyim, Neyse uzatmayayım. Burada anlatılan şey şu: veri katmanı eski alışkanlıklarla yönetilmiyor artık.
OpenAI Cephesi: Sıfırdan Petabayta, Aynı Anda
Bak şimdi, Konferansta en çok aklımda kalan oturum, açık konuşayım, OpenAI’dan Jon Lee’nın anlattıklarıydı. Trilyonlarca transaction, petabyte’larca veri… Rakamlar zaten başlı başına göz yoruyor ama Jon’un asıl derdi sayı değildi (ki bu çoğu kişinin gözünden kaçıyor)
“En önemli şey”, dedi Jon, “sıfırdan milyonlarca QPS’e çıkabilmek, sıfır bayttan petabyte’a evrilebilmek.” Yanı mesele sadece büyük olmak değil. Asıl iş, hızlı şekil değiştirebilmek. Kısacası, peki neden? Çünkü sistem büyürken de kıpır kıpır kalmak zorunda.
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.
İşte tam da bu noktada devreye giriyor.
Bu arada SQL Server tarafında da hava değişiyor. Azure SQL’de AI_GENERATE_EMBEDDINGS GA: T-SQL ile Vektör Devri yazımda anlattığım gibi, klasik relational dünya da vektör desteğini içine alıyor; hani bu da seçimi daha ince hâle getiriyor,. Artık “sadece NoSQL mi?” sorusu o kadar düz değil.
Startup’lar için tablo farklı
Aslında, Küçük bir ekipseniz ve MVP peşindeyseniz, Cosmos DB serverless tier ile başlamak baya iş görüyor. Mantıklı değil mi? Aylık 5-50 dolar bandında ciddi bir prototip çıkarabiliyorsunuz; sonra işler büyürse Enterprise tier’a geçersiniz, ama başta oraya abanmanın pek anlamı yok gibi dürüyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Eğer kurumsal yapıdaysanız ve compliance, residency, audit gibi gereksinimleriniz varsa — ki Türkiye’de neredeyse her finans ya da sağlık kuruluşunda var — provisioned throughput ve reserved capacity hesabını yapmak şart. Yoksa faturayı görünce yüzünüz düşer, ben söyleyeyim; çünkü küçük görünen tüketim bazen sessizce büyüyor. Sonradan can sıkıyor.
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.
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
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder