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?”

Haklılar tabii. Parlak tarafı göstermek kolay. DiskANN ile vektör araması, columnstore ile analitik — demo’da insanı etkiliyor, ona lafım yok. Ama production’a taşıyan şey bunlar değil; güvenlik politikalarının aynı çizgide kalması, backup’ın tek parça olması, API katmanının dağılmaması… işin zor kısmı tam burası.

Şimdi gelelim işin can alıcı noktasına.

Bugün o zor kısımlara gireceğiz. Hem de Türkiye’deki kurumsal müşterilerde gördüğüm gerçek örneklerle.

Polyglot Mimaride Güvenlik Kâbusu

Bence, Şöyle düşünün: Bir fintech firmasındasınız. Müşteri verisi PostgreSQL’de, graf ilişkileri Neo4j’de, vektör embedding’leri Pinecone’da, analitik veri ClickHouse’ta. Her birinin authentication yapısı ayrı. Yetkilendirme modeli ayrı. Audit log düzeni de ayrı.

Kaç tane güvenlik politikası yönetiyorsunuz? Beş. En az beş.

Geçen yıl bir bankacılık projesinde birebir bununla uğraştık. Müşteri KVKK denetimi için “şu kullanıcı hangi verilere erişebiliyor” sorusuna cevap gerekiyordu (evet, doğru duydunuz). Her veritabanı için — kendi adıma konuşayım — ayrı rapor çıkardık — ve açık konuşayım, bu raporların birbirini tuttuğunu denetçilere anlatmak hiç kolay olmadı. E peki, sonuç ne öldü? Haftalar sürdü.

Tek Motor, Tek Güvenlik Politikası

SQL Server 2025’te multi-model yaklaşımın en sevdiğim tarafı burada ortaya çıkıyor. Row-Level Security (RLS) tanımlıyorsunuz — bir kere. Sonra bu politika relational tabloya da, JSON verisine de, graf kenarlarına da, vektör embedding’lerine de uygulanıyor. Otomatik olarak.

Kısa bir not düşeyim buraya.

Multi-tenant bir SaaS uygulaması düşünelim. Her tabloda TenantID kolonu var. Kiracı A, kiracı B’nın verisini görmemeli. İşte bunu tek fonksiyonla ve tek security policy ile toparlıyorsunuz:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);
CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, — Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, — JSON verisi
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, — Graf kenarları
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings — Vektör verisi
WITH (STATE = ON);

Bitti gitti gibi dürüyor ama mesele aslında burada başlıyor. SESSION_CONTEXT uygulama tarafında ya da Data API — ki bu tartışılır — Builder içinde connection başına set ediliyor; kullanıcı oraya dokunamıyor. E peki, sonuç ne öldü? Sorgu relational join olsa da olur, JSON path query olsa da olur, MATCH traversal olsa da olur, vektör similarity search olsa da olur — filtre yine devreye giriyor.

Bunu ilk test ettiğimde ben de biraz şüpheciydim doğrusu (en azından benim deneyimim böyle). “Graf traversal’da gerçekten çalışıyor mu?” dedim kendi kendime. Çalışıyorymuş meğer. Execution plan’a bakınca filter predicate’in her operatörün altına oturduğunu görüyorsunuz; optimizer bunu ayrı bir katman gibi değil de sorgunun doğal parçası gibi işliyor.

Polyglot vs Tek Motor: Güvenlik Karşılaştırması

Bunu biraz somutlaştıralım mı? Aşağıdaki tablo, beş farklı veritabanı kullandığınız polyglot mimariyle SQL Server 2025 tek motor mimarisini güvenlik açısından yan yana koyuyor:

Bunu Logosoft’ta bir sunum için hazırlamıştım. Müşterinin güvenlik ekibi tabloyu görünce “tamam ya, anladık” dedi — şaka değil bu. Mesela audit log tutarlılığı konusu Türkiye’deki finans ve sağlık sektöründe çok kilit oluyor (en azından benim deneyimim böyle). BDDK ve KVKK denetimlerinde beş farklı log formatını birleştirmek gerçekten can sıkıcı.

Güvenlik bir özellik değil — mimarı kararın doğal sonucu gibi düşünün önü. Polyglot mimaride güvenliği sonradan yamamaya çalışırsınız. Tek motor mimarideyse güvenlik zaten orada, en baştan beri.

Yedekleme ve Kurtarma: Tutarlılık Meselesi

Peki yedekleme? Aslında bazen güvenlikten bile daha can yakıcı oluyor bu konu. Bu konuyla ilgili güvenlik konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim. Codex Kurumsal Ölçekte: Ne Vaat Ediyor, Ne Eksik? yazımızda bu konuya da değinmiştik.

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. Node.js Addon’larını.NET Native AOT ile Yazmak yazımızda bu konuya da değinmiştik.

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. Bu konuyla ilgili Kubernetes’te AI Agent Sandbox: Pratik Rehber yazımıza da göz atmanızı tavsiye ederim.

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 DATABASE komutu ç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. Bu konuyla ilgili Kubernetes’te Production Debug Güvenliği: Rehber yazımıza da göz atmanızı tavsiye ederim.

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.

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.
Tabii 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İ

1. Mevcut polyglot mimarinizi haritalayın : Hangi veritabanları hangi veri modelleri için kullanılıyor ? Aralarında transactional tutarlılık gerekiyor mu ?
2. 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.
   <>
3. > Güvenliği sona bırakmayın.
   SESSION_CONTEXT + filter predicate yapısını en baştan koyun.
   <>
4. MCP Server’ı yapılandırın :> Agent erişimi için stored procedure’leri tool olarak expose edin.
   Minimum yetki prensibiyle başlayın.
   <>
5. > Kendi verinizle, kendi sorgularınızla test edin.
   Blog yazılarından çok kendi sonuçlarınıza bakın.
   <>

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

İlgili Yazılar

Azure SDK Ekim 2025: Yapay Zekâdan Kimlik Yönetimine Dikkat Çeken Yenilikler18 Mar 2026

ABD Devletine Açılan Sır Kapısı: Azure Top Secret Bulutta Yapay Zekâ ve Verinin Yeni Çağı24 Mar 2026

Kubernetes AI Gateway WG: AI Trafiği Artık Standart20 Nis 2026

AI Projelerinde Azure Blob’a Bağlanmak Hiç Bu Kadar Kolay Olmamıştı: adlfs Deneyimi18 Mar 2026