Geçen hafta Cosmos Conf 2026 sunumlarını izlerken kafamda bir şey dönüp durdu: artık veritabanı dediğimiz şey, eskiden bildiğimiz veritabanı gıbı değil. Hani 10 yıl önce “schema tasarla, indeks at, sorguyu optimize et” diye yaşıyorduk ya — o dünya yavaş yavaş kenara itiliyor. Yerine ne geliyor? İşte önü yazmak istedim.
Açık konuşayım, ben de ilk başta biraz temkinliydim. Her konferansta bir “AI everywhere” lafı dönüyor ve çoğu zaman işin yarısı pazarlama gürültüsü oluyor. Ama Cosmos Conf’ta Kirill Gavrylyuk’un açılış konuşmasını ve özellikle OpenAI’dan Jon Lee’nın oturumunu dinleyince — durdum, bir düşündüm. Burada gerçekten yapısal bir kayma var. Sadece “yeni bir feature eklendi” meselesi değil.
İşte tam da bu noktada devreye giriyor.
Bu yazıda hem konferanstan çıkardığım üç ana sinyali anlatacağım, hem de Türkiye’deki kurumsal müşterilerimde gördüğüm pratik tarafı paylaşacağım. Çünkü Microsoft’un Redmond’daki vizyonu ile İstanbul’daki bir bankanın gerçekliği bazen ayrı dünyalar gıbı duruyor, bunu da yok saymamak lazım.
AI Is Yükü “Sadece Bir Is Yükü” Değil
Bak şimdi, Konferansın özünü tek cümlede toparlasam şunu derim: AI artık veritabanının üstüne sonradan eklenen bir uygulama değil, veritabanını yeniden tarif eden bir yapı oluyor. Bu lafı ilk duyduğumda “tamam, biraz fazla büyütmeyelim” dedim. Ama detaylara indikçe bazı yerlerde haklı olduklarını görüyorsunuz.
Düşünün bir kere. Geleneksel bir CRM uygulaması yazıyorsanız müşteri tablosunun şeması bellidir; ad, soyad, e-posta, telefon… Beş yıl sonra bile büyük ölçüde aynı kalır. Ama bir AI agent yazıyorsanız ne saklıyorsunuz? Prompt geçmişi, konuşma context’i, vektör embedding’leri, tool call sonuçları, memory snapshot’ları… Bunların hiçbiri sabit şemalı değil; her hafta yeni bir alan ekliyorsunuz çünkü model değişiyor (biraz), retrieval stratejiniz değişiyor (daha çok), agent’in hafıza yapısı değişiyor (evet). İşte burada iş karışıyor.
Kirill’in söylediği “systems of record” yerine “systems of reasoning” fikri tam da bu noktada yerine oturuyor. Veritabanı artık sadece kaydın tutulduğu yer değil; uygulamanın akıl yürütmesine zemin hazırlayan altyapı hâline geliyor.
“Veriyi katı şemalara hapsetmek, AI hızında geliştirme yapan ekipler için artık rahatlık değil — tersine ayağa takılan bir şey.” Kirill bunu birebir böyle demedi ama mesajın özü buydu.
Semi-Structured Veri Neden Bu Kadar Önemli?
Geçen ay bir e-ticaret müşterimizde tam bu sıkıntıyı yaşadık. RAG tabanlı bir ürün arama asistanı kuruyorduk; ilk hafta şema şuydu: ürün başlığı, açıklama, embedding vektör, kategori. İkinci hafta “kullanıcı niyet skoru” geldi. Üçüncü hafta “konuşma geçmişi referansı” eklendi. Dördüncü hafta agent tool çağrılarını da saklamamız gerektiğini fark ettik. Eğer bunu PostgreSQL’de katı şema ile yapıyor olsaydık her hafta migration script kovalamak zorunda kalacaktık; Cosmos DB’nın JSON document yapısında işe yeni alan eklemek daha çok “bir property daha koyup devam et” işi gıbı duruyor.
Bu arada şeyi de söyleyeyim — schema-less her derde deva değil. Bir noktada disiplini sen koymak zorundasın; yoksa altı ay sonra dökümanlarda 47 farklı alan ölür ve hangisinin ne olduğu kimsenin aklında kalmaz. Biz bu yüzden ekip içinde JSON Schema validator kullanıyoruz (dökümanlar yazılmadan önce kontrolden geçiyor). Esnek olmak başka şeydir, başıboş olmak başka. MAESTRO ile Microsoft SQL: Agentic AI Güvenliği yazımızda bu konuya da değinmiştik.
Geliştirme Hizti: Sıfırdan Milyonlara Bir Hafta Içinde
OpenAI’dan Jon Lee’nın oturumu bence konferansın en somut kısmıydı. Adam trilyonlarca transaction ve petabayt seviyesinde veriden söz ediyor ama asıl vurgu yaptığı şey “ne kadar büyük olduğumuz” değildi; “ne kadar hızlı değişebildiğimiz” idi.
Jon’un kullandığı bir cümle aklımda kaldı: “Sıfır QPS’ten milyonlara, sıfır bayttan petabaytlara çıkabilmek.” Buradaki can alıcı kelime gerçekten “sıfır.” Yanı ben yeni özelliği prod’a attığımda kullanıcı gelmeden kapasiteyi önceden yığmıyorum; geldiğinde sistem büyüyor (gittiğinde küçülüyor). Eski dünyada böyle değildi açıkçası — SQL Server cluster’ları için aylar öncesinden kapasite planlaması yaptığımız günleri hatırlıyorum da… Daha fazla bilgi için Visual Studio Agent Skills: Copilot’a Takımı Öğretmek yazımıza bakabilirsiniz. Bu konuyla ilgili GitHub App Token Formatı Değişiyor: Override Header Rehberi yazımıza da göz atmanızı tavsiye ederim.
Coding Agent’lar Işin Rengini Değiştiriyor
Şahsen, Bir başka nokta şu: artık kodu yazan tek başına insan değil. Copilot, Cursor, Claude Code, GitHub Copilot Workspaces… Bu agent’lar geliştiricinin yanında ikinci el gıbı çalışan ekip arkadaşı rolüne giriyor (bazen fazla hevesli oluyorlar ama olsun). Bunun sonucu da net: üretilen kod miktarı artıyor, deploy sayısı artıyor, deney sayısı artıyor. Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımızda bu konuya da değinmiştik.
Bizim Logosoft’taki bir sigorta projesinde geçen çeyrek 14 deploy yapmıştık; bu çeyrek aynı ekip 41 deploy yaptı. Aynı kişilerdi bunlar. Neden? Çünkü Copilot Business’ta bir düşüneyim… Yeni Dönem: GPT-5.3-Codex Devrede yazımda da değindiğim gıbı kod yazma hızı son bir yılda bayağı değişti. Veritabanının da buna ayak uydurması gerekiyor; yoksa darboğaz oraya toplanıyor ve sonra herkes birbirine bakıyor.
Bakın, Şimdi startup tarafında tablo açık: serverless Cosmos DB ile başla, kullandığın kadar öde, ölçek otomatik gelsin diyoruz genelde Peki büyük kurumsal yapılarda? Orada iş biraz yön değiştiriyor.
Evet.
Türkiye’deki Kurumsal Gerçeklik
Bu kısım kaynak makalede yok ama bence en önemli parçalardan biri bu olabilir aslında; çünkü Türkiye’de Cosmos DB benimsenme hikâyesi biraz farklı akıyor.
Önce maliyet meselesi var tabi. Cosmos DB serverless modelde request unit (RU) başına ücretlendirme yapıyor ve dolar bazında bakınca Amerikan startup için mesele olmayabiliyor ama TL kuru devreye girince tablo değişiyor açıkçası.Geçen sene bir fintech müşterimde tam bu hesabın üstünde üç hafta tartıştık: provisioned throughput mu olsun, serverless mı, autoscale mi? Sonunda autoscale’e karar verdik çünkü gece-gündüz trafiği baya farklıydI; yanı sabah başka, gece başka davranıyordu sistem.
Maalesef.
İkincisi veri ikametgâhı konusu var.KVKK ve sektörel regülasyonlar yüzünden (özellikle finans ve sağlık tarafında) verinin nerede tutulduğu kilit hâle geliyor.Cosmos DB’nın Türkiye region’ı henüz olmadığı için çoğu zaman West Europe veya North Europe’a çıkıyoruz; bu da hem latency hem de regülasyon tarafında ekstra konuşma gerektiriyor.Banka müşterilerimde bu konu bazen projeyi iki ay geciktiriyor, abartmıyorum.
Küçük Ekip vs Büyük Kurumsal Hangı Yaklaşım?
Küçük bir detay: Bu soruyu çok alıyorum; kısa kısa yazayım: Daha fazla bilgi için GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza bakabilirsiniz.
Şimdi gelelim işin can alıcı noktasına.
Peki neden?
| Senaryo | Öneri | Neden |
|---|---|---|
| 5-10 kişilik startup MVP aşamasında | Cosmos DB Serverless | Sıfır operasyon kullandığın kadar öde |
| Orta ölçek SaaS tahmin edilebilir trafik | Autoscale provisioned | Maliyet daha kontrol edilebilir peak’lerde de rahat |
`
Sıkça Sorulan Sorular
Serverless mi, provisioned mi? Hangisi daha mantıklı?
Kendi deneyimimden konuşuyorum, Trafiğin ne zaman geleceğini bilemiyorsan — mesela geliştirme ortamı, küçük bir POC ya da düşük trafikli bir SaaS projesi — serverless tam sana göre (evet, doğru duydunuz). Ama trafik sürekli ve tahmin edilebilirse autoscale provisioned daha ekonomik oluyor. Açıkçası ben çoğu prod yükü için autoscale’i tercih ediyorum; trafik patladığında otomatik büyüyor, sakinleşince minimuma iniyor. Hani ikisinin de güzelliğini bir arada yaşıyorsun.
Cosmos DB’nın vektör araması Pinecone’un yerine geçer mi?
Orta ölçek için büyük ihtimalle geçer. Aynı platformda hem OLTP hem vektör arama yapmak operasyonel açıdan ciddi bir kolaylık sağlıyor, bence bu çok hafife alınan bir avantaj. Yanı iki ayrı sistemi yönetmek zorunda kalmıyorsun (buna dikkat edin). Ama 100 milyonu aşan vektörlerde ve gerçekten milisaniyeler önemli olan senaryolarda specialized çözümler hâlâ bir tık önde. Çoğu kurumsal RAG uygulaması için Cosmos DB fazlasıyla yeterli.
Türkiye’den veri ikametgâhı meselesini nasıl çözüyoruz?
Kısacası, küçük bir detay: Şu an için Cosmos DB’de Türkiye region’ı yok. Çoğu kişi West Europe (Hollanda) ya da North Europe (İrlanda) kullanıyor. Kişisel veri işliyorsan KVKK kapsamında yurt dışı aktarım için aydınlatma metni ve açık rıza süreçlerini gözden geçirmen gerekiyor (yanlış duymadınız). Savunma veya kamu gıbı kritik sektörlerde işe bu seçenek hiç mümkün olmayabiliyor, aslında oralarda işin başından alternatif mimarilere bakmak daha sağlıklı.
Şimdi gelelim işin can alıcı noktasına.
RU maliyetini nasıl hesaplarım?
Azure Cosmos DB Capacity Calculator var, oradan başla. Ama tecrübeme göre en doğru yöntem küçük bir POC kurup gerçek trafik altında bir hafta çalıştırmak. Metrics’ten gerçek RU tüketimini görürsün, ona göre plan yaparsın. Kâğıt üzerindeki tahminler pratikte genelde %30-40 sapıyor — hani sürpriz olmasın diye söylüyorum.
Cosmos Conf sunumlarını sonradan izleyebilir mıyım?
Aslında — hayır dür, daha doğrusu, Evet! Microsoft genelde tüm oturumları hem YouTube’da hem de Microsoft Learn üzerinde yayınlıyor. Kayıtlara aşağıdaki kaynaklar bölümündeki linkten ulaşabilirsin.
Kaynaklar ve İleri Okuma
Build AI apps with Azure Cosmos DB: Key trends from Cosmos Conf 2026 (Orijinal Makale)
Azure Cosmos DB Resmî Dokümantasyonu
Cosmos DB Vector Search Rehberi
Azure Cosmos DB Developer Blog
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.
