SQL Server 2025’te Güvenlik ve MCP: Tek Motor Yeter mi?
Bakın, son birkaç haftadır çevremde SQL Server 2025’in multi-model tarafını anlatıp duruyorum. JSON var, graf var, vektör var, columnstore var… Hepsini tek veritabanında çalıştırmak kulağa baya iyi geliyor. Ama konuşma bir noktada hep aynı yere dönüyor: “Tamam da güvenlik ne olacak? Yedekleme gerçekten tutarlı mı? Agent’lar buna nasıl bağlanacak?”
📋 İçindekiler
-
Bunu yaşayan biri olarak söyleyeyim, Ppolyglot mimaride her veritabanını ayrı yedekliyorsunuz. Ama şu soru ortada kalıyor : Bu sistemler arasında transactional tutarlılık gerçekten var mıydı ? Büyük ihtimalle yoktu.
Bunu e-ticaret üzerinden düşünün. Sipariş PostgreSQL’de, ödeme bilgisi başka yerde, ürün vektörleri Pinecone’da. Backup’lar farklı zamanlarda alınıyor. Felaket anında restore ediyorsunuz ; sipariş var ama ödeme yok, ya da ödeme var ama sipariş kayıp. Buna split-brain backup diyorlar, ben işe dümdüz “felaket” diyorum.
Tek Motor = Tek Transaction Log = Atomik Backup
SQ L Server 2025’te JSON veriniz de, graf ilişkileriniz de, vektör embedding’leriniz de aynı transaction log’a yazılıyor.
BAC KUP DATABASEkomutu çalıştığında hepsi aynı noktadan alınıyor. Point-in-time recovery yapabiliyorsunuz ve tüm veri modelleri o ana dönüyor. Hepsi birlikte.2024 ‘ ün sonunda bir telekom müşterisinde yaşadığımız olay bunu baya iyi gösterdi. Hani bazen sorun yaşamadan anlamıyorsunuz ya, işte tam öyleydi. Müşteri hem relational hem JSON veri kullanıyordu ama bunları ayrı veritabanlarında tutuyordu. Disk arızasından sonra restore sırasında JSON veritabanı 15 dakika geride kaldı. O 15 dakikalık farkı düzeltmek tam 3 gün sürdü. Tek veritabanında olsaydı ? Sıfır gün.
$ Bilgi : Azure SQL Hyperscale kullanıyorsanız backup zaten arkada sürekli alınıyor. Point-in-time recovery 35 güne kadar destekleniyor. Multi-model veriyi tek veritabanında tutup Hyperscale ile eşleştirdiğinizde, felaket kurtarma senaryolarında ciddi rahatlık sağlıyor.MCP : Veritabanını Agent’lara Açmak
Gelelim benim en çok heyecanlandığım kısma. Model Context Protocol — MCP. Daha önce SQL MCP Server : Veritabanını Ajanlara Açmanın Yolu yazısında bunu detaylı anlatmıştım. Ama bugün başka açıdan bakacağız : multi-model veritabanıyla MCP birleşince ne oluyor ?
Normalde bir AI agent’ın veritabanına erişmesi için ne yapıyordunuz ? Her endpoint için ayrı API yazıyordunuz. REST endpoint’leri, GraphQL şemaları, vektör arama servisleri… Her biri için ayrı kod, ayrı bakım, ayrı güvenlik derdi.
MCP ile SQL Server 2025 birleştiğinde agent doğrudan veritabanındaki stored procedure’leri tool olarak kullanabiliyor. Ve o stored procedure’ün içinde — Part 3 ‘te gördüğümüz gibi — beş farklı veri modeline tek transaction içinde erişebiliyorsunuz.
Agent ‘ lar İçin Güvenlik Katmanı
Ha, dur bir saniye. “Agent doğrudan veritabanına erişiyor” deyince güvenlikçilerin kaşı kalktı biliyorum ; haklılar da aslında. Ama burada birkaç önemli nokta var :
- Agent, veritabanına kendi kimliğiyle bağlanıyor — her agent’ın ayrı service principal ‘ı var
- Row-Level Security agent bağlantılarında da geçerli — agent sadece yetkili olduğu veriyi görebiliyor
- Stored procedure’ler EXECUTE AS ile minimum yetki prensibine uygun çalışıyor
- SQL Server Audit, agent’ın her sorgusunu logluyor
- Dynamic Data Masking ile hassas alanlar agent’tan bile gizlenebiliyor
Bunu ilk kurduğumuzda — açık konuşayım — biraz tedirgin olmuştum.
Bir agent’ın production veritabanına doğrudan erişmesi fikri insana tuhaf geliyor.
Ama RLS + audit + masking birleşince ortaya fena olmayan bir güvenlik katmanı çıkıyor.
Tabiî sıfır risk diye bir şey yok ; yine de polyglot mimarideki beş ayrı API’nın beş ayrı açık yüzeyine göre tek ve iyi korunan giriş noktası çok daha yönetilebilir dürüyor.Bu konuyla bağlantılı olarak Cosmos DB Dynamic Data Masking : Veri Güvenliğinde Yeni Dönem yazısına da göz atabilirsiniz — masking tarafını orada başka yerden anlatıyorum.
Türkiye’de Bu Mimarinin Benimsenmesi
Kurumlar açısından bakalım şimdi; bu yapı Türkiye’de ne kadar yürür?
Küçük ekipseniz—hani üç beş kişilik startup diyelim—zaten polyglot mimariye gitmenize gerek yok büyük ihtimalle.
SQL Server Express ya da Azure SQL Basic tier ile başlayın.
JSON ve relational veriyi aynı yerde tutun.
İş büyüdükçe Hyperscale’e geçersiniz.
MCP’yi de en baştan koyarsanız ileride agent entegrasyonu gerektiğinde eliniz rahat olur.
Evet.Kurumsal tarafta iş biraz değişiyor.
Türkiye’deki büyük bankalarda ve telekom şirketlerinde yıllardır Oracle ya da DB2 ile çalışan legacy sistemler var.
“Hadi hepsini SQL Server’a taşıyalım” demek kolay değil.
Ama yeni projelerde—özellikle AI agent’larla entegre olacak işlerde—SQL Server 2025’in multi-model yaklaşımına bakmak bence mantıklı.
Yatırım maliyeti düşük kalıyor.
Operasyonel karmaşıklık azalıyor.
Güvenliği yönetmek de daha sade hâle geliyor.”Maliyet tarafına da değineyim; çünkü genelde burası atlanıyor.
Azure SQL Database’de Hyperscale tier’da iki vCore ile başlıyorsunuz—aylık kabaca 300-350 dolar civarı.
Bunu beş ayrı managed servisin toplamıyla kıyaslayın:
Pinecone,
Neo4j Aura,
ClickHouse Cloud,
PostgreSQL managed…
Her biri başka fatura.
Her biri başka reserved capacity kararı.
FinOps açısından tek motor yaklaşımı baya iş görüyor açıkçası.Nope.
Açık söyleyeyim; bazı yerlerde hâlâ soru işareti dürüyor.
DiskANN vektör araması kötü değil ama henüz Pinecone kadar olgun hissettirmiyor—özellikle çok büyük vektör kümelerinde (100M+ kayıt) performans kıyasını görmek istiyorum.
Graf sorguları Neo4j kadar esnek değil; Cypher’ın gücü hâlâ MATCH syntax’ının önünde dürüyor gibi.
Columnstore tarafı da bazı senaryolarda ClickHouse’un gerçek zamanlı analitik temposuna yetişemiyor.
Ama burada küçük ama önemli bir şey var:
Eğer bunları tek tek karşılaştırıyorsanız asıl resmî kaçırıyorsunuz demektir.
Mesele tek özelliğin en iyi olması değil ki.
Mesele hepsinin tek çatı altında,
tek güvenlik politikasıyla,
tek backup akışıyla,
tek transaction boundary içinde çalışmasıdır.
Bu bütünlük çoğu kullanım senaryosunda bireysel performans farklarını fazlasıyla dengeliyor.
Yine de şöyle bir durum var:
Eğer yalnızca tek veri modeline abanıyorsanız—mesela sadece graf analizi yapan bir şirketseniz—o zaman dedicated çözüm hâlâ daha mantıklı olabilir.
Multi-model her derde deva değil;
ama çoğu kurumsal senaryoda gayet yeterli oluyor.
AI Maliyet Optimizasyonu : ROI ‘ yi Gerçekten Artırmanın Yolu
yazısında anlattığım gibi,
bu tür mimarı kararların uzun vadeli maliyet etkisi,
kısa vadeli performans farklarından çoğu zaman daha belirleyici oluyor.
Neyse,
konuyu dağıtmayayım ;
ama burası önemli.
PRAKTİK BAŞLANGIÇ REHBERİ
- Mevcut polyglot mimarinizi haritalayın : Hangi veritabanları hangi veri modelleri için kullanılıyor ? Aralarında transactional tutarlılık gerekiyor mu ?
- SQ L Server 2025 Preview’u kurun : Bir test ortamında JSON, graf ve vektör özelliklerini deneyin.
Mevcut verilerinizin küçük bir alt kümesiyle başlayın.
<> - > Güvenliği sona bırakmayın.
SESSION_CONTEXT + filter predicate yapısını en baştan koyun.
<> - MCP Server’ı yapılandırın :> Agent erişimi için stored procedure’leri tool olarak expose edin.
Minimum yetki prensibiyle başlayın.
<> - > Kendi verinizle, kendi sorgularınızla test edin.
Blog yazılarından çok kendi sonuçlarınıza bakın.
<>
$ İpucu :
Azure SQL Database ‘de Hyperscale tier kullanıyorsanız,
bu multi-model özelliklerin hepsini managed servis olarak alabilirsiniz.
Sunucu yönetimi,
patching,
backup —
hepsi otomatik akar gider.
İlk denemeler için serverless compute tier seçerseniz,
kullanmadığınız saatlerde ödeme yapmazsınız.Sıkça Sorulan Sorular
SQL Server 2025’te Row-Level Security tüm veri modellerinde çalışıyor mu?
Evet, çalışıyor. Yanı relational tablolar, JSON içeren tablolar, graf node/edge tabloları, vektör embedding tabloları — hepsi aynı security policy kapsamına girebiliyor. Filter predicate de tüm sorgu türlerinde (JOIN, JSON_PATH, MATCH, vector search) otomatik devreye giriyor. Aslında bu entegrasyon bence en güzel yanı.
MCP ile agent’ın veritabanına doğrudan erişmesi güvenli mi?
“Doğrudan erişim” tek başına tabiî ki riskli olabilir. Ama hani SQL Server’ın RLS, Dynamic Data Masking, EXECUTE AS, SQL Audit gibi katmanlarını birlikte kullanınca iş ciddi anlamda sağlamlaşıyor. Tecrübeme göre en kritik adım şu: her agent’a ayrı service principal tanımlayın ve minimum yetki prensibini mutlaka uygulayın.
Polyglot mimariden tek motora geçiş ne kadar sürer?
İtiraf edeyim, Bu bayağı mevcut karmaşıklığınıza bağlı. Mesela küçük bir projede 2-4 hafta yetebilir. Büyük kurumsal sistemlerde işe kademeli geçiş yapmanızı öneririm — önce yeni projelerden başlayın, legacy’ye acele etmeyin. Açıkçası 6-12 aylık bir plan çoğu zaman en makul seçenek oluyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Azure SQL Hyperscale’de multi-model veri için ek maliyet var mı?
Hayır, yok. JSON, graf ve vektör özellikleri için ekstra lisans ücreti ödemiyorsunuz, standart Hyperscale fiyatlandırması geçerli. Maliyet, compute ve storage tüketiminize göre şekilleniyor. Bence asıl karşılaştırmayı polyglot mimarideki 5 ayrı servisin toplam maliyetiyle yapın — genellikle çok daha ucuza geliyor.
SQL Server 2025’in vektör araması Pinecone kadar hızlı mı?
Küçük ve orta ölçekli vektör setlerinde (10M kayıta kadar) DiskANN gayet rekabetçi bir performans veriyor. Çok büyük setlerde (100M+) ve düşük latency gerektiren senaryolarda dedicated vektör veritabanları hâlâ avantajlı olabilir tabiî. Ama açıkçası çoğu kurumsal kullanım senaryosu için SQL Server fazlasıyla yeterli.
Kaynaklar ve İleri Okuma
The Polyglot Tax – Part 4: The Agent-Ready Database (Microsoft DevBlogs) (inanın bana)
Aşkın KILIÇYazar20+ 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İlgili Yazılar
İlginizi Çekebilir
Kaan T.
Row-Level Security’nin tek politikayla hem JSON hem graf hem vektör verilerini kapsaması gerçekten çekici geliyor, ama pratikte ne kadar sorunsuz çalışıyor merak ediyorum. Bu arada güvenlik tarafında ilginizi çekebilir: https://www.askinkilic.com.tr/azure-sdk-nisan-2026-kritik-guvenlik-yamasi-ve-yenilikler/
Elif D.
Row-Level Security’yi zaten kullanıyoruz ama vektör ve graf verilerini aynı politika altında yönetebilmek gerçekten işleri kolaylaştırır. Acaba performans tarafında bu çok modelli yapı ek yük getiriyor mu, bunu merak ediyorum.
Yorumlar kapalı.
2 comments