Geçen hafta bir fintech müşterisindeydim. Üç ay önce kurdukları RAG mimarisini gösterdiler bana. Vektör için Pinecone, sohbet geçmişi için Redis, agent state için ayrı bir Postgres, semantic cache için yine Redis ama başka bir cluster, üstüne LangGraph checkpointer için MongoDB. Beş ayrı servis. Beş ayrı fatura. Beş ayrı izleme paneli. Ve hâliyle… beş ayrı baş ağrısı.
Vallahi, Adamların DevOps lideri masaya oturdu, “Aşkın bey, biz bu mimariyi kuralı 90 gün öldü, hâlâ production’a alamadık. Latency tutarsız, maliyet öngörülemiyor, biri çökünce hangı servis sebep olmuş anlayamıyoruz” dedi. İşin aslı şu ki, bu hikâyeyi son bir yılda en az 5-6 kez dinledim. Şaşırdım mı? Pek değil. Şimdi Microsoft’un yayınladığı langchain-azure-cosmosdb paketi de tam bu noktaya dokunuyor.
Lafı gevelemeden anlatayım: Cosmos DB for NoSQL artık LangChain ve LangGraph dünyasında tek persistence katmanı gıbı konumlanıyor. Vektör arama, sohbet geçmişi, agent checkpoint, semantic cache, long-term memory — hepsi tek veritabanında, tek SDK ile dönüyor.
Neden ayrı bir konnektör? Yanı gerçekten gerekli mıydı?
İlk gördüğümde ben de “yine bir paket daha mı” dedim açıkçası. Ama kodu kurcalayınca fikir biraz değişti. Bakın şimdi, klasik bir agentic uygulamada şu bileşenler çoğu zaman ayrı ayrı çözülüyor:
- Vektör arama: Pinecone, Weaviate, Qdrant ya da Azure AI Search
- Chat history: Redis veya bir doküman DB — ciddi fark yaratıyor
- Agent state checkpointing: Postgres ya da SQLite (LangGraph’ın varsayılanı)
- Semantic cache: Redis Vector ya da başka bir cache çözümü
- Long-term memory: Genelde elle yazılmış custom bir katman
İtiraf edeyim, Beş bileşen. Beşi de farklı SDK demek. Beşi de ayrı SLA, ayrı network gecikmesi, ayrı güvenlik ayarı demek. Global dağıtım yapmaya kalkınca iş iyice karışıyor — biri Avrupa’da kalıyor, biri Amerika’da sürünüyor, eventual consistency derken sistem çorba oluyor.
Cosmos DB zaten ChatGPT’nın sohbet geçmişlerini tuttuğu veritabanı tarafında kullanılıyor. OpenAI bunu milyarlarca kayıt için çalıştırıyor. Yanı ölçek tarafı çoktan test edilmiş durumda; biz sadece üstüne LangChain abstraction’ını ekliyoruz.
Pakette neler var? Altı entegrasyon, hepsi sync ve async
Kendi deneyimimden konuşuyorum, Paketle birlikte gelen entegrasyonları toplu hâlde görmek daha rahat oluyor, çünkü tek tek döküman okumak biraz yoruyor insanı:
| Entegrasyon | Sync Sınıf | Ne işe yarıyor? |
|---|---|---|
| Vector Store | AzureCosmosDBNoSqlVectorSearch | Vektör + full-text + hibrit + ağırlıklı hibrit arama |
| Semantic Cache | AzureCosmosDBNoSqlSemanticCache | LLM yanıtlarını cache’le, maliyet ve gecikme düşür |
| Chat History | CosmosDBChatMessageHistory | Sohbet geçmişi, TTL desteğiyle |
| LangGraph Checkpointer | CosmosDBSaverSync | Multi-turn agent için graph state kalıcılığı |
| LangGraph Cache | CosmosDBCacheSync | Düğüm bazında sonuç cache’leme |
| LangGraph Store | CosmosDBStore | Namespace destekli long-term memory + semantic search |
Hani, Bunların async versiyonu da var. Yanı FastAPI ile production’a gidecekseniz blocking I/O yüzünden kafanız ağrımaz. İyi tarafı bu.
Hızlı kurulum
Pip tarafı gayet düz:
pip install langchain-azure-cosmosdbKodun auth kısmında iki yol var: klasik access key ya da Microsoft Entra ID (Managed Identity). Ben kurumsal işlerde genelde Managed Identity tarafını seçiyorum — access key’i Key Vault’a koysanız bile rotation işi insanı yoruyor. Bu konuyu daha önce Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşti yazımda detaylı anlattım; oraya da bakabilirsiniz.
Peki pratikte nasıl görünüyor?
Kuru kuru API dökümantasyonu yazmayayım dedim ama en azından mantık net olsun diye küçük bir örnek bırakayım:
from langchain_azure_cosmosdb import AzureCosmosDBNoSqlVectorSearch
from langchain_openai import AzureOpenAIEmbeddings
embeddings = AzureOpenAIEmbeddings(model="text-embedding-3-large")
vector_store = AzureCosmosDBNoSqlVectorSearch(
cosmos_client=client,
embedding=embeddings,
database_name="agent_db",
container_name="documents",
vector_embedding_policy={...},
indexing_policy={...},
)
# Hibrit arama — vektör + full-text birlikte
results = vector_store.hybrid_search(
query="Cosmos DB autoscale nasıl çalışır?",
k=5,
)
Bakın, Dikkat ettiyseniz ortada ayrıca bir search engine yok. Cosmos DB’nın kendi vektör + lexical + hybrid search özellikleri kullanılıyor. Bu da şunu getiriyor: tek RU/s bütçesi, tek partition stratejisi, tek izleme ekranı (ki bu çoğu kişinin gözünden kaçıyor). Fena değil yanı.
Nerede işe yarar? Türkiye tarafında bakalım mı?
Açık konuşayım, bu paket herkese göre değil. Türkiye’deki müşteri portföyünü düşününce ben bunu ikiye ayırıyorum:
Kurumsal yapılar (banka, sigorta, telekom, kamu)
Bence burada baya iş görüyor. Neden? Çünkü Cosmos DB zaten lisanslı oluyor çoğu yerde, zaten Azure içinde duruyor, zaten Entra ID ile konuşabiliyor (bizzat test ettim). Üstüne bir de Pinecone gıbı ekstra vendor yönetmek; procurement tarafında ayrı dert, KVKK ve veri ikametgahı tarafında ayrı dert. Geçen yıl bir devlet bankasında Pinecone önerisini açtım; hukuk ekibi iki hafta uğraştıktan sonra “veri Türkiye dışına çıkamaz” dedi. Plan baştan çizildi.
Burası önemli aslında: Cosmos DB’nın bölge seçenekleri ve Azure içindeki yerleşimi sayesinde bu tür projelerde operasyon biraz rahatlıyor (tabii senaryoya göre yine dikkat etmek lazım). Tam sihir değil ama elinizi hafifletiyor.
Startup’lar ve küçük ekipler
Küçük ekiplerde tablo değişiyor. Eğer 5-10 kişilik bir takımsanız ve MVP peşindeyseniz Cosmos DB’nın RU/s modeli ilk başta kafa karıştırabiliyor. Nasıl desem… idare eder ama herkesin alışacağı türden değil. Bu durumda Supabase + pgvector ya da Qdrant Cloud daha pratik olabilir — fiyatlama daha tahmin edilebilir geliyor insana (ben de ilk duyduğumda şaşırmıştım)
Ama trafik büyümeye başlayınca iş değişiyor; özellikle kampanya ve lansman gıbı burst anlarında RU/s autoscale gerçekten nefes aldırıyor (en azından benim deneyimim böyle). O noktada Cosmos DB tarafına tekrar bakmak gerekiyor. Bu konuyla ilgili .NET’in Composable AI Stack’i: ConferencePulse Vakası yazımıza da göz atmanızı tavsiye ederim.
Maliyet tarafı: TL bazında ne çıkıyor?
Kafadan konuşmayalım diye kaba bir hesap yaptım. Tipik orta ölçekli bir RAG uygulamasını düşündüm (günde yaklaşık 50K sorgu, 1M doküman, 1536-dim embedding):
- Ayrı servisler senaryosu: Pinecone Standard (~$70/ay) + Redis Cloud (~$50/ay) + Postgres ($30/ay) + monitoring/logging ek $40 → yaklaşık ~$190/ay, kabaca 6.500-7.000 TL bandı.
- Cosmos DB tek katman: Autoscale 4000 RU/s civarı → yaklaşık ~$240/ay, yanı 8.000 TL civarı.
Dışarıdan bakınca Cosmos DB pahalı gıbı görünüyor olabilir, evet. Ama burada gözden kaçan iki şey var: Birinçisi DevOps adam-saati; ayrı servislerle çalışırken her ay 2-3 gün operasyonel iş çıkabiliyor — buna rahatlıkla 15-20 bin TL ekleyin. İkincisi de servislerin birbirine konuşurken oluşturduğu egress maliyeti.
Bunu daha ayrıntılı hesapladığım Cosmos DB Maliyet Optimizasyonu: AI Yüklerinde 7 Taktık yazısına da göz atabilirsiniz. Bu konuyla ilgili GPT-5.2 ve GPT-5.2-Codex Emekli Oluyor: Geçiş Notları yazımıza da göz atmanızı tavsiye ederim.
Nihayetinde tablo şu: hacim büyüdükçe Cosmos DB’nın tek-katman modeli daha avantajlı hâle geliyor. Düşük trafikte işe ayrı servisler bazen daha ucuz kalabiliyor. Yanı “her yere uyar” demek doğru olmaz.
Kafa yoran tuzak: Indexing policy meselesi
Evet burada küçük ama sınır bozucu bir detay varmış meğersem deneme yaparken anladım. Geçen ay bir e-ticaret müşterisinde bu paketi denerken hata aldım; vektör arama çalışıyordu, full-text çalışıyordu. Hani ne farkı var diyorsunuz, değil mi? Hibrit arama boş dönüyordu sürekli.
Neredeyse üç saat debug ettikten sonra fark ettim ki indexing policy içinde full-text path’leri tanımlamamışım. Cosmos DB’nın lexical search özelliği varsayılan indexing’le gelmiyor; açıkça belirtmeniz gerekiyor. Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımızda bu konuya da değinmiştik.
Bunun çözümü şöyleydi: Bu konuyla ilgili Azure Cosmos DB Conf 2026: Notlarım, İzlenimlerim ve yazımıza da göz atmanızı tavsiye ederim.
taggering_policy = {
"indexingMode": "consistent",
"fullTextIndexes": [
{"path": "/text"}
],
"vectorIndexes": [
{"path": "/embedding", "type": "diskANN"}
]
}Dökümanda yazıyor aslında ama insan kolay atlıyor işte. İlk denemenizde böyle takılırsanız şaşırmayın; yalnız değilsiniz.
Neleri eksik buldum?
Tamamen pembe tablo değil tabii ki. Birkaç yerde kaşıntı var diyeyim:
Biri şu:, observability tarafı hâlâ biraz ham duruyor bana göre. LangSmith entegrasyonu iş görüyor ama Cosmos DB’ye özgü metrikler (RU tüketimi, partition hot-spotting gıbı) için ayrıca Application Insights kurmanız gerekiyor. Tek yerde toplanmış bir gözlem deneyimi olsaydı daha rahat olurdu. Daha fazla bilgi için agent ile ilgili önceki yazımız yazımıza bakabilirsiniz.
Biri de şu:, Mongo vCore versiyonu için ayrı paket bekliyordum açıkçası; şu an odak NoSQL API’de kalmış durumda. Mongo vCore kullanan müşteriler biraz kenarda kalıyor gıbı hissediliyor.
Eh, Son olarak:, dökümandaki örnekler fazla happy path kokuyor diyebilirim.
Production senaryosunda rate limiting ne olacak? Retry policy nasıl kurulacak? Partial failure geldiğinde ne yapılacak? Bunlar çok net değil.
Bu eksiklere benzer şeyleri Microsoft Agent Framework’te Chat History: Nerede. yazısında da konuşmuştuk aslında — Microsoft’un AI ekosistemi hızlı büyüyor ama dokümanlar aynı hızda koşamıyor bazen.
Peki production’a almadan önce neye bakarım?
Böyle bir paketi kurumsal projeye sokacaksanız ben olsam şu listeyi baştan kontrol ederim; hatta bizim ekipte verdiğim checklist aşağı yukarı böyleydi:
- Partition key stratejisini baştan seçin.
Tenant bazlı mı olacak, kullanıcı bazlı mı? Sonradan değiştirmek pahalıya patlıyor. - Zaman bütçesi ve alarm kurun.
Vektör sorguları RU yiyor; özellikle hibrit arama bunu iyice artırabiliyor.
Application Insights üzerinden alert şart gıbı düşünün.
TTL’leri unutmayın.
** Chat history container’ında TTL yoksa veri birikiyor,
maliyet sessiz sessiz şişiyor.
Evet.
”
Managed Identity ile auth kurun.
** Access key’lerle production’a çıkmayın,
lütfen.”
Async versiyonları kullanın.
** Sync olanlar prototipte tamam,
gerçek yükte async daha rahat ediyor.”
Embedding boyutunu doğru seçin.
** 3072 yerine 1536 çoğu zaman yeterli oluyor;
disk ve RU tarafında fark baya hissediliyor.”[/ol]
Sıkça Sorulan Sorular
Bu paket Azure Cosmos DB for MongoDB ile çalışıyor mu?
Şu an için hayır. Paket spesifik olarak Cosmos DB for NoSQL API’sı için yazılmış,. MongoDB vCore kullanıyorsanız
langchain-mongodbpaketine devam etmeniz gerekiyor. Mongo vCore desteği ileride gelir mi? Açıkçası henüz net bir roadmap açıklaması yok.Vektör araması için ayrıca bir Azure AI Search’e ihtiyaç var mı?
Çoğu senaryoda hayır, aslında gerek kalmıyor. Cosmos DB’nın yerleşik vektör + full-text + hibrit search özellikleri standart RAG ihtiyaçları için gayet yeterli. Siz ne dersiniz? Ama mesela çok karmaşık relevance tuning, semantic ranker ya da skill-based enrichment gıbı şeyler gerekiyorsa Azure AI Search hâlâ daha güçlü bir seçenek olarak duruyor.
LangGraph checkpointer ile agent state ne kadar süre saklanıyor?
Şahsen, Bu tamamen container TTL ayarınıza bağlı. Varsayılan olarak süresiz tutuluyor, ama bu — özellikle yüksek trafikli agent’larda — maliyetli olabiliyor. Tecrübeme göre production’da 30-90 günlük TTL kurmak mantıklı. Kritik agent’lar için de ayrı bir “permanent” container tasarlamanızı öneririm.
Mevcut Pinecone tabanlı bir RAG uygulamasını taşımak ne kadar zor?
Şunu fark ettim: Aslında düşündüğünüz kadar zor değil. Embedding’leri yeniden hesaplamadan geçebiliyorsunuz — vektörleri export edip Cosmos DB’ye import etmek mümkün (evet, doğru duydunuz). Ortalama bir ekip için 1-2 haftalık bir migration projesi sayılır. Asıl dikkat edilmesi gereken kısım indexing policy. Partition key tasarımı; bunları doğru kurarsanız geri kalan API farklarına alışmak çok kolay.
Türkiye’den hangı region’ı seçmeliyim?
Şu an Türkiye region’ı yok, en yakını West Europe (Hollanda) ve North Europe (İrlanda). Latency açısından West Europe genelde 35-45 ms civarında geliyor, bence fena sayılmaz. Veri ikametgahı sizin için kritikse Microsoft ile EU Data Boundary anlaşması üzerinden bir çözüm üretmek mümkün — ama bunu hukuk birimleriyle baştan netleştirin derim.
Kaynaklar ve İleri Okuma
Açık konuşayım, langchain-azure-cosmosdb PyPI Sayfası
Azure Cosmos DB for NoSQL Vector Search Resmî Dokümantasyonu
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.
