Geçen hafta İstanbul’da bir sigorta şirketinin mimarlık ekibiyle masa başındaydık. Konu şuydu: AI ajanlarını mevcut SQL Server filolarına nasıl bağlayacağız? Adam doğrudan database’e connection string verip “büyür sorgula” demek istemiyor — haklı da. Çünkü bir agent’a SQL erişimi verdiğiniz anda, hem güvenlik hem de tutarlılık tarafında kapı bir anda ardına kadar açılıyor.
Doğrusu, İşte tam o toplantıda konuşulan şey, Microsoft’un son aylarda iyice toparladığı SQL MCP Server’dı. Konuyu ben de uzun zamandır izliyordum ama müşteri net sordu: “Bizim container stratejimiz yok Aşkın bey, biz App Service’te çalışıyoruz. Bunu container’siz çalıştırabilir mıyız?” Hmm, asıl can alıcı soru buydu bence.
Cevap kısa: evet, çalıştırabilirsiniz. Hem de fena olmayan bir yöntemle. Bu yazıda nasıl yaptığımı, neden iş gördüğünü ve sahada insanın başını ağrıtan küçük tuzakları anlatacağım.
SQL MCP Server Tam Olarak Ne Işe Yarıyor?
Bunu yaşayan biri olarak söyleyeyim, Lafı dolandırmadan söyleyeyim. MCP, yanı Model Context Protocol, bir AI agent’in dış dünya ile konuşmasını sağlayan bir protokol. SQL MCP Server da bunun SQL tarafındaki hâli; yanı agent ile veritabanı arasına giren bir aracı katman. Kısa cevap bu. Ama işin tadı burada başlıyor.
Neden böyle bir şeye ihtiyacımız var? Çünkü agent’a doğrudan SQL connection string vermek, stajyere production sunucusunun root şifresini uzatmak gıbı bir şey. Risk açıkça yüksek. Onun yerine kontrollü bir API yüzeyi veriyorsunuz, agent da sadece sizin tanimladiginiz entity’lerle. Sizin izin verdiğiniz operasyonlarla ilerliyor. Bu kadar basit, ama fark baya büyük.
Burada hoşuma giden kısım su: SQL MCP Server aslında Data API Builder (DAB)’in üstüne kurulmuş. Yanı DAB’in caching, telemetry, authentication ve entity-based abstraction gıbı yanlarını doğrudan alıyorsunuz (ben de ilk duyduğumda şaşırmıştım). Güzel taraf bu. Bir de üstüne bonus geliyor; aynı DAB konfigürasyonu hem MCP, hem REST, hem de GraphQL endpoint’i sunabiliyor (tek runtime, üç kapı), hani bazen insan “tamam burada fazla temiz olmuş” diyor.
Bunu ilk duyduğumda şöyle düşündüm: “Tamam, agent için MCP, mobil için REST, frontend için GraphQL — hepsi aynı config’ten.” Açık konuşayım, bu baya akıllı duruyor. Genelde Microsoft tarafında her şey bu kadar düzgün akmaz; bazen orada burada ufak pürüzler çıkar.
Container Yolu Neden Herkes İçin Değil?
Standart deployment modeli container, evet. Docker image build edersin, registry’ye push edersin, sonra AKS ya da Container Apps’e deploy edersin. Ölür yanı. Ama işin aslı, her ekip o akışa aynı rahatlıkta girmiyor.
İşte tam da bu noktada devreye giriyor.
Garip gelecek ama, Türkiye’deki kurumsal müşterilerde gördüğüm tablo biraz daha farklı. Hele bir de finans ve kamu tarafında ekiplerin %60-70’i hâlâ App Service ya da VM tabanlı gidiyor; container stratejisi ya hiç oturmamış oluyor ya da yeni yeni başlıyor, hani böyle “bakacağız” seviyesinde kalıyor. Bir bankacılık projesinde bana açıkça şöyle demişlerdi: “Aşkın bey biz Kubernetes’e operasyonel olarak hazır değiliz, lütfen container önermeyin.”
Vallahi, Bu noktada iki yol çıkıyor karşınıza. Ya zorla container’a geçeceksiniz (ki bu çoğu zaman 6-12 aylık bir dönüşüm oluyor, üstüne eğitim var, süreç var, güvenlik var), ya da SQL MCP Server’ı container’siz çalıştıracaksınız. Açık konuşayım, ikinci seçenek PoC’de ve orta ölçek senaryolarda baya iş görüyor.
Kime Container, Kime App Service?
Karar verirken kafamda şöyle bir tablo oluşuyor. Kısa cevap bu.
| Senaryo | Önerim | Neden? |
|---|---|---|
| Startup, küçük ekip, AKS yok | App Service | Operasyonel yük minimum |
| Mevcut Kubernetes platformu var | Container | Standart pratiğe uy |
| Multi-region, yüksek ölçek | Container Apps / AKS | Scale ve failover daha esnek |
| Tek bölge, orta yük, kurumsal | App Service | TLS, Entra, monitoring hazır |
| Hibrit/on-prem zorunluluğu | VM + dab CLI | En esnek, en az bağımlılık |
Peki neden böyle? Çünkü kağıt üstünde container çok temiz duruyor ama sahada bazen başka şeyler konuşuyoruz (evet, doğru duydunuz). Mesela küçük bir ekipte AKS kurup yönetmek mantıklı olmayabiliyor; buna karşılık zaten Kubernetes kullanan bir organizasyonda aynı işi container ile yürütmek gayet doğal geliyor.
Neyse uzatmayayım. Tek bölge çalışan orta ölçekli bir kurumsal yapıda App Service çoğu zaman yeterli oluyor; TLS hazır geliyor, Entra entegrasyonu kolaylaşıyor ve monitoring tarafı uğraştırmıyor. Ama multi-region veya ciddi scale ihtiyacı varsa iş değişiyor, orada Container Apps ya da AKS daha rahat nefes aldırıyor.
Evet.
Şunu fark ettim: Bazen de hibrit tarafta işler karışıyor. On-prem zorunluluğu varsa veya bağımlılığı minimumda bir düşüneyim… tutmak istiyorsanız VM ile ilerlemek daha sakın bir yol olabiliyor; dab CLI tarafı da burada devreye giriyor. Şey yanı, herkes için tek doğru yok.
Bence asıl mesele ne?
Bence mesele “container iyi mi kötü mü” değil (yanlış duymadınız). Mesele şu: ekibin operasyonel olgunluğu ne durumda ve siz bu çözümü hangı hızda hayata geçirmek istiyorsunuz? Çünkü bazen teknik olarak en düzgün görünen seçenek bile ekibi yorabiliyor (özellikle ilk geçişte), sonra proje yavaşlıyor ve kimse mutlu ölmüyor.
Siz ne dersiniz? Denediniz mi hiç? Benim gözlemim şu: doğru yerde App Service hâlâ gayet makul duruyor; container işe ihtiyaç gerçekten varsa anlam kazanıyor.
Yanı, Tam da öyle.
Data API Builder CLI: Işin Kalbi
Bütün iş, aslında dab CLI ile başlıyor. Kısa, net. Cross-platform çalışıyor,.NET üstüne kurulu, Docker ya da Kubernetes de istemiyor; yanı yerelde de ölür, bir VM’de de ölür, App Service’te de, açık konuşayım pek fark etmiyor.
Yanı, Komut tarafı da öyle uzatılacak gıbı değil:
# DAB CLI'yi kur
dotnet tool install -g Microsoft.DataApiBuilder
# Yeni bir config oluştur
dab init --database-type "mssql" \
--connection-string "@env('SQL_CONN')" \
--host-mode "Production"
# Bir entity ekle (ornek: Musteri tablosu)
dab add Musteri --source dbo.Musteri \
--permissions "anonymous:read"
# MCP'yi ac
# (dab-config.json içinde "mcp": { "enabled": true })
# Calistir
dab startHepsi bu kadar. dab start deyince runtime ayağa kalkıyor, config’i okuyor. MCP endpoint’ını host ediyor; sonra aynı şey yerelde de çalışıyor, Azure App Service’te de — hani bazen araçlar ortam değişince nazlanır ya, bunda o numara pek yok. Bu konuyla ilgili Visual Studio 2026 Nisan: Copilot Agent’ları Devreye Girdi yazımıza da göz atmanızı tavsiye ederim.
dab start çalıştırdığınızda http://localhost:5000/mcp adresinden MCP endpoint’inize ulaşabiliyorsunuz. VS Code’un Copilot ajanını lokal MCP’ye bağlayıp test etmek özellikle ilk denemelerde baya iş görüyor; ben olsam önce bunu denerim, sonra canlı tarafa geçerim.Azure App Service’e Deployment: Adım Adım
Şimdi asıl kısma geldik. Bunu App Service’e nasıl koyacağız? Geçen ay bir bankacılık müşterisinde aynı işi yaptık, o yüzden adımları taze taze yazıyorum; biraz pratik, biraz da “şurayı atlamayın” tadında olacak.
Çok konuştum, örnekle göstereyim.
1. App Service Plan ve Web App Hazırlığı
Bir şey dikkatimi çekti: Önce Linux tabanlı bir App Service plan açıyorsunuz, ardından.NET 8 runtime seçiyorsunuz. SKU tarafında ben genelde B2 ya da P1v3 ile başlıyorum; B1 bazen yetmiyor, çünkü DAB runtime ilk açılışta biraz RAM yiyor (özellikle birkaç entity tanımlıysa), sonra insan “niye bu kadar ağır başladı” diye bakakalıyor.
TL ile düşününce tablo fena değil: P1v3 aylık kabaca 130-150 USD civarında geziyor. Container Apps consumption modunda daha ucuza inebilirsiniz, evet, ama operasyon tarafını da hesaba katınca App Service hâlâ iş görüyor. Hatta bazen, şey, beklediğinizden daha rahat oluyor.
2. Konfigürasyon Dosyası ve Bağımlılıklar
Bilmem anlatabiliyor muyum, Repo’nün kökünde dab-config.json dosyası duracak. Bunun yanına minicik bir wrapper proje koyabilirsiniz ya da doğrudan dab tool’unu App Service üzerinde startup command olarak çağırabilirsiniz; ben açık konuşayım, ikinci yol daha az uğraştırıyor.
App Service içindeki Configuration -> General Settings -> Startup Command alanına şunu yazın: (ben de ilk duyduğumda şaşırmıştım)
dotnet tool install -g Microsoft.DataApiBuilder --tool-path./tools &&./tools/dab start --config-file./dab-config.json --no-https-redirectİlginç olan şu ki, Tabii bu hâli biraz kaba duruyor. Production’da bunu bir startup script’e almak, log toplama işini de düzgün kurmak lazım; yoksa sonra “neden çıktı alamıyoruz” diye uğraşırsınız. Ama mantık aynı kalıyor.
3. Bağlantı Dizesi ve Managed Identity
Burada durun, çünkü önemli nokta bu. Connection string’i App Settings’e plaintext olarak yazmayın; yazarsanız kısa vadede kolay gelir ama sonra başınız ağrır. Onun yerine Managed Identity kullanın: (ciddiyim)
- App Service’e System-assigned Managed Identity verin
- Bu identity’yi SQL Database’de kullanıcı olarak ekleyin (
CREATE USER... FROM EXTERNAL PROVIDER) - Connection string’de
Authentication=Active Directory Defaultkullanın - DAB yapılandırmaunda
data-source.options.access-tokenkısmını Entra ile çözmesini sağlayın
Bunu kurduğunuzda ortada SQL şifresi dolaşmıyor, işin aslı bu kadar net. Bir finans projesinde aynı yaklaşımı devreye aldığımızda denetim ekibi baya rahatlamıştı — onları memnun etmek kolay değildir, bilen bilir. Evet.
4. Authentication Katmanı: Entra ID
Daha açık söyleyeyim, bir şey dikkatimi çekti: App Service’in Authentication sekmesinden Microsoft Entra ID’yi açın. Ondan sonra MCP endpoint’ınız token olmadan çağrılamaz hâle geliyor; yanı kapı biraz sıkılaşıyor, fena da ölmüyor aslında. Agent tarafında da bu token’ı taşımanız gerekecek,. Microsoft Agent Framework ya da başka bir agent SDK’sı kullanıyorsanız akış oldukça doğal ilerliyor.
Şimdi gelelim işin can alıcı noktasına. Bu konuyla ilgili Microsoft OpenJDK Nisan 2026 Yaması: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.
Bu konuya daha detaylı bakmak isterseniz, Microsoft Agent Framework:.NET’te Akıllı Ajan Devri yazımda agent tarafındaki entegrasyonu adım adım anlatmıştım. Yukarıda bahsettiğim o olay var ya, işte orada token akışıyla ilgili kısmı biraz daha açıyorum.
Sahada Karşılaştığım 3 Tuzak
Yanı, Teoride her şey temiz duruyor. Ama sahaya inince iş değişiyor, hani o klasik hikâye var ya; canlıya çıkarken bir anda ufak görünen detaylar büyüyor, gecenin bir yerinde sızı yakalıyor ve “bunu neden baştan düşünmedik” dedirtiyor.
Cold Start Süresi
App Service’i Free veya Basic SKU’da bırakırsanız, cold start süresi 8-15 saniyeyi buluyor. Bir agent için bu baya sıkıntı,. Kullanıcı beklerken sistem de sanki uykudan zor kalkıyor; Always On ayarını açın, mümkünse Premium SKU’ya geçin (P1v3 tarafında cold start neredeyse hissedilmiyor), yoksa ilk istek geldiğinde suratınız düşüyor.
Evet.
WebSocket ve SSE
MCP, transport olarak HTTP+SSE (Server-Sent Events) kullanıyor. App Service bunu destekliyor, ama bir yerde takılabiliyor işte: Web Sockets ayarını “On” yapmayı unutursanız bağlantı stabil kalmıyor; ben bir kere unuttum, agent her seferinde yaklaşık 2 saniye sonra kopuyordu. Açık konuşayım, dört saatim gitti. mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımızda bu konuya da değinmiştik.
Peki neden?
Connection Pool Şişmesi
DAB her request için yeni bağlantı açmıyor, pool kullanıyor. Güzel tarafı bu. Ama entity sayısı artınca. Trafik sıklaşınca SQL tarafında sp_who2 çektiğinizde listenin uzayıp gittiğini görüyorsunuz (şey gıbı, bitmiyor sanıyorsunuz); data-source.options.max-pool-size değerini buna göre ayarlayın, çünkü default değer çoğu senaryoda biraz fazla cömert kalıyor.
Tam da öyle.
Türkiye Perspektifinden Bir Değerlendirme
Bi saniye — Açık konuşayım: SQL MCP Server, Türkiye’deki kurumsal pazara baya oturan bir teknoloji. Neden? Çünkü buradaki şirketlerin çoğu hâlâ SQL Server üstünde dönüyor, bir yandan da agentic AI tarafına geçmek istiyorlar; ama “veritabanımı doğrudan ChatGPT’ye nasıl açarım?” sorusu uzun süre havada kaldı. İşte cevap bu, en azından şimdilik.
Gel gelelim, işin parlak tarafı kadar pürüzlü tarafı da var. MCP protokolü daha yeni sayılır — şubat-mart 2025 civarında netleşmeye başladı, yanı öyle yıllardır pişmiş bir yapı değil; tooling de sürekli kıpırdıyor, bugün yazdığınız kod altı ay sonra biraz başka bir şeye dönüşebilir. Bu yüzden ben şu an PoC. Internal araçlarda gaz verin derim, ama mission-critical canlı sistemlerde biraz frene basmak daha mantıklı geliyor; 6 ay sonra resim zaten daha net olacak.
Bunu biraz açayım.
Bir de şu var: MCP üzerinden veriye erişen bir agent, “ne kadar veriyi nereye taşıdığını” default’ta tam loglamıyor. Yanı GDPR/KVKK açısından bakınca ek logging katmanı koymanız şart gıbı duruyor. Biz müşterilerde Azure Monitör ile custom telemetry’yi birlikte kullanıyoruz şu ara — detayına burada girmeyeyim, konu uzar — ama akılda kalması gereken nokta bu (inanın bana)
Pratik İpuçları: İlk Adımlar
Eğer bu yazıyı okuyup da “tamam, ben de bir bakayım” diyorsanız, bence işi fazla büyütmeden başlayın. Lokalde deneyin; küçük bir SQL veritabanı açın, 1-2 entity tanımlayın, sonra dab start ile ayağa kaldırıp /mcp endpoint’ını Postman ya da curl ile yoklayın. Basit duruyor, evet; ama ilk tık orada geliyor.
- Lokalde başlayın.
dabCLI’yı kurun, küçük bir test SQL veritabanı oluşturun, 1-2 entity tanımlayın.dab startçalıştırıp/mcpendpoint’ını Postman veya curl ile test edin. - VS Code Copilot ile bağlayın. MCP client config’ine local endpoint’ınızı ekleyin. Copilot’a “Müşteri tablosundan son 10 kaydı listele” gıbı bir komut verin. Çalışıyorsa nefes alın.
- App Service’e deploy edin. Önce dev ortamında, B2 SKU ile. Managed Identity ve Entra auth’u atlamayın.
- Telemetry ekleyin. Application Insights bağlayın, hangı entity’lerin ne kadar çağrıldığını takıp edin.
- Production’a sadece review’dan sonra geçin. Permission yapısını ekibinizdeki güvenlik kişisiyle birlikte gözden geçirin.
MCP tarafında iş bazen “şey bu kadar mı?” dedirtiyor, ama asıl mesele bağlantıyı kurmak değil; doğru yerde sınır koymak (özellikle yetki ve erişim tarafında) daha can alıcı oluyor. Yukarıda anlattığım akışta bir adımı atlayınca sorun hemen çıkmayabilir, fakat production’a yaklaşınca o eksik parça sızı uğraştırıyor; o yüzden önce dev’de dene, sonra loglara bak, en son da güvenlik kontrolünü yap. İşte pratik olan bu.
Evet, doğru duydunuz.
Ayrıca bu süreçle ilgili .NET’te MCP Tool Çağrılarını AGT ile Yönetmek: Saha Notları yazımda agent tarafındaki tool yönetimini anlatmıştım; oraya da göz atın derim, çünkü burada anlattığım kurulumla oradaki akış birbirini baya tamamlıyor. Neyse uzatmayayım, bağlantıyı kurduktan sonra asıl farkı orada görüyorsunuz zaten.
Maliyet Tarafında Düşünceler
Şunu söyleyeyim, Bir müşteri “Aşkın bey bu kaç para?” diye sorduğunda, ben de içimden hızlıca hesap yapıyorum. App Service P1v3 + Standard SQL Database S2 + Application Insights basic tier derken, aylık 280-350 USD bandında bir runtime maliyeti çıkıyor; üstüne bir de agent tarafında OpenAI ya da Azure OpenAI token masrafı ekleniyor, o kısım da kullanım arttıkça hafiften şişiyor.
Peki neden?
İşte mesele burada. Container Apps ile aynı işi kurarsanız, çoğu senaryoda %20-30 daha ucuza gelebiliyor, ama dür bir saniye — operasyonel yükü (yanlış duymadınız). Öğrenme eğrisini de kenara koyamazsınız (çünkü ucuz diye seçip sonra ekipte iki kişi geceleri log kovalamaya başlarsa o tasarruf pek tatlı gelmiyor).
Küçük bir ekipseniz, açık konuşayım, App Service ile devam etmek daha rahat oluyor (en azından benim deneyimim böyle). Ama 50+ kişilik bir platform ekibiniz varsa işler değişiyor; Container Apps o zaman baya iş görüyor. Evet.
Sıkça Sorulan Sorular
SQL MCP Server, Data API Builder’dan ayrı bir şey mi?
Eh, Hayır, ayrı bir ürün değil aslında. Data API Builder’ın bir özelliği olarak geliyor. Yanı hani aynı dab-config.json dosyasına "mcp": { "enabled": true } ekliyorsunuz, MCP endpoint’i açılıyor. REST ve GraphQL endpoint’leri de aynı anda çalışmaya devam ediyor, bir şey değişmiyor (evet, doğru duydunuz)
Container kullanmadan App Service’te performans sıkıntısı yaşar mıyım?
İtiraf edeyim, Pratikte hayır. App Service zaten.NET runtime için optimize edilmiş bir platform — bence bu konuda çok düşünmeye gerek yok (kendi tecrübem). Cold start dışında ciddi bir fark görmedim açıkçası. Premium SKU ve Always On açıkken container’lı versiyonla karşılaştırdım, ortalama latency farkı 5-10 ms bandında kalıyor.
SQL MCP Server’ı on-premise SQL Server ile kullanabilir mıyım?
Bir bakıma, bi saniye — Evet, kullanabilirsiniz. DAB hangı SQL Server’a bağlandığıyla pek ilgilenmiyor zaten — connection string ne diyorsa oraya gidiyor. Tabii App Service’ten on-prem SQL’e erişmek için Azure VNet integration ya da hybrid connection kullanmanız gerekiyor.
Agent’ın hangı tablolara erişeceğini nasıl kısıtlarım?
DAB yapılandırmaunda her entity için ayrı ayrı permissions tanımlıyorsunuz. Mesela hangı role hangı operasyona izin var, kayıt seviyesinde hangı filtreler uygulanacak (yanı “sadece kendi şubesinin verisini görsün” gıbı şeyler) — hepsi config’ten yönetiliyor. Yanı agent’a “her şeyi gör” demek zorunda değilsiniz, bu kısmı çok seviyorum açıkçası.
Durun, bir saniye.
Production’da kullanmaya hazır mı?
Bence evet, ama dikkatli olmakta fayda var. PoC ve internal tooling için rahat kullanın. Müşteriye dönük kritik süreçlerde işe önce küçük bir scope’la başlayın. Telemetry’i sıkı tutun, permission modelini de güvenlik ekibinize bir gözden geçirtin. MCP protokolü hâlâ olgunlaşıyor; tecrübeme göre böyle durumlarda biraz değişikliğe hazırlıklı olmak işleri çok kolaylaştırıyor.
Kaynaklar ve İleri Okuma
Daha açık söyleyeyim, bi saniye — Data API Builder Resmî Dokümantasyonu — DAB’in pek çok özelliklerini ve konfigürasyon detaylarını burada bulabilirsiniz.
SQL MCP Server as an App Service (Microsoft DevBlog) — Bu yazıya ilham veren orijinal duyuru. Teknik walkthrough.
Data API Builder GitHub Repository — Source kodu, issue tracker ve güncel CLI sürümü için birinci adres.
Model Context Protocol Resmî Sitesi — MCP protokolünün kendisini ve referans implementasyonlarını öğrenmek için.
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.
