Açık konuşayım: Müşteri toplantılarında son altı aydır en sık duyduğum cümle şu — “Aşkın, biz de şu ChatGPT gıbı bir şey istiyoruz, kullanıcı yazsın, veritabanından cevap gelsin.” Kulağa hoş geliyor, hatta bayağı çekici bir fikir. Ama ben bunu duyunca içimden hep aynı ses geçiyor: “Dür bakalım hemşerim.” Çünkü işin mutfağına girince tablo biraz değişiyor, hatta bazen epey dağılıyor.
NL2SQL, yanı Natural Language to SQL. Kullanıcı doğal dille soruyu yazıyor, model SQL üretiyor, veritabanı cevaplıyor. Üç adım gıbı duruyor. Ama o üç adımın arasında küçük bir köprü yok; bildiğin okyanus var. Bu yazıda hem o okyanusu anlatacağım, hem de Microsoft’un yeni çıkardığı SQL MCP Server tarafının neyi çözüp neyi çözmediğine kendi gözümden bakacağım.
İşin Aslı Şu: Modeller Veritabanınızı Tanımıyor
Şimdi şöyle düşünün. Siz bir bankada 15 yıldır çalışan kıdemli bir DBA’sınız. Birisi gelip “müşteri bakiyelerini getir” dese, hangı tablodan, hangı join ile, hangı filtre ile çekeceğinizi biliyorsunuz. Çünkü o şemayı yaşamışsınız. CUST_M_BAL_T tablosunun aslında müşteri bakiyesi değil, “mutabakat bakiyesi” tuttuğunu, gerçek bakiyenin ACC_BAL_DLY‘de olduğunu biliyorsunuz; üstüne bir de STATUS_CD=7 olanları çıkarmazsanız kapatılmış hesaplar da araya karışıyor.
Peki model bunu nereden bilecek? Bilmiyor. Tahmin ediyor. Ve tahmin ettiği şey de çoğu zaman çalışıyor gıbı görünen ama yanlış cevap döndüren bir SQL oluyor (bizzat test ettim). Kısacası sorun burada başlıyor.
2023 sonunda bir telekom müşterimde tam olarak bu duvara çarptık. POC aşamasında modele şemayı verdik, “aktif abone sayısı” diye sorduk. Model düzgün bir SQL üretti, sonuç geldi: 4.2 milyon. Sevindik tabi. Sonra iş birimi geldi ve “bu sayı yanlış, biz 3.7 milyonuz” dedi. Meğer modelin kullandığı view, iptal sürecindeki aboneleri de “aktif” sayıyormuş; çünkü iptal lifecycle’ı 30 gün sürüyormuş. cancel_pending statüsü teknik olarak aktif sayılıyormuş. Şemada böyle bir not yok tabi. Bu iş kuralı sadece bir Word dosyasında ve Mehmet abinin kafasında duruyormuş.
Şemalar veriyi saklar ve bütünlüğü korur — iş kurallarını anlatmaz. Bu cümleyi bir yere yazıp masanızın üstüne yapıştırın. NL2SQL serüvenine çıkmadan önce.
Şema Tek Başına Yetmiyor — Peki Ontoloji Çözüm mü?
Vallahi, Son aylarda ontoloji kelimesi yeniden moda öldü. Hatırlarsanız 2010’larda “data dictionary” furyası vardı; herkes bir Excel açıp tabloları açıklamaya başlamıştı. Sonra o dosyalar güncellenmedi, kimse dönüp bakmadı ve yavaş yavaş çöp öldü gitti. Şimdi aynı hikâyeyi LLM çağında tekrar yaşıyoruz, ama bu sefer etiket değişti: adı ontoloji.
Vallahi, Ontoloji aslında mantıklı bir fikir: Veriyi sadece teknik olarak değil, anlamsal olarak da tarif edelim. “Bu tablo müşteri demek, (söylemesi ayıp) bu kolon vergi numarası demek, bu ilişki şu durumda geçerli, şu durumda değil.” Güzel duruyor. Ama küçük bir pürüz var: ontoloji veriyi anlatır, nasıl sorgulanacağını anlatmaz.
Yanı modele “aktif müşteri ne demek” diye anlatsanız bile, bunu performanslı bir T-SQL’e çevirmek hâlâ modelin sırtında kalıyor. Ve modeller burada bayağı yaratıcı olabiliyor; hatta bazen biraz fazla yaratıcı oluyorlar.
Türkiye Bağlamında Bir Parantez
Türkiye’deki kurumsal müşterilerde gördüğüm bir şey var: Bizim şemalar Türkçe-İngilizce karışık oluyor. MUSTERI_TBL, fatura_detay, tblOrderHeader… Üç farklı dönemden üç farklı geliştirici ekibinin izi üst üste binmiş gıbı duruyor. Üstüne bir de KVKK geliyor; bazı kolonlar maskeli, bazıları view üzerinden açılıyor. Model bu kaosun içinde gezinirken halüsinasyon görme ihtimali bence Batı’daki daha temiz şemalara göre %30-40 daha yüksek. Bunu hiçbir benchmark açık açık söylemiyor ama saha bana bunu gösteriyor.
SQL MCP Server Nereye Oturuyor?
Şimdi gelelim asıl meseleye. Microsoft, Model Context Protocol (MCP) için SQL Server tarafında bir şey yayınladı. MCP’yi bilmeyenler için kısa özet bir düşüneyim… şu: Anthropıc’in başlattığı, sonra herkesin sarıldığı bir standart var ortada; ajan ile dış sistemler arasında köprü kuruyorlar (buna dikkat edin). USB-C gıbı düşünün — her ajan her veri kaynağına aynı fişle bağlansın istiyorlar.
Peki neden? Daha fazla bilgi için notları konusundaki yazımız yazımıza bakabilirsiniz.
SQL MCP Server işe bu protokolün SQL tarafındaki implementasyonu. Ama dikkat edin: Bu sadece “veritabanına SQL gönder” aracı değil. Asıl değer önerisi bence başka yerde duruyor — modelin önüne ham şema atmak yerine, Data API Builder (DAB) üzerinden tanımlı ve kontrollü endpoint’ler sunuyorsunuz.
Yanı model gidip “bana HR.Employees tablosundan select çek” demiyor artık; onun yerine “GetActiveEmployees” diye tanımladığınız aracı çağırıyor. Arkada ne çalıştığını siz kontrol ediyorsunuz (hangı filtreler var, hangı kolonlar maskeli, hangı yol kapalı). İşte fark burada. Bu konuyla ilgili GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza da göz atmanızı tavsiye ederim.
Iki Yaklaşım: Açık Şema vs Kontrollü Endpoint
Tuhaf ama, Bu konuyu netleştirmek için iki yaklaşımı yan yana koymak lazım: Bu konuyla ilgili Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımıza da göz atmanızı tavsiye ederim.
| Kriter | Klasik NL2SQL (şema prompt’ta) | SQL MCP Server + DAB |
|---|---|---|
| Kontrol | Düşük — model her şeyi görüyor | Yüksek — sadece tanımlı endpoint’ler |
| Esneklik | Yüksek — her şey sorgulanabilir | Orta — önceden tanımlanmış işlemler |
| Halüsinasyon riski | Yüksek | Düşük |
| Güvenlik | SQL injection vektörü açık | Parametreli, doğrulanmış |
| Tasarlanmış for prod |
Siz bu tabloya bakınca ne anlıyorsunuz? Eğer küçük bir startup’sanız, içeride üç kişi varsa ve hızlıca POC çıkarmak istiyorsanız klasik NL2SQL idare eder. Hatta açık konuşayım, Copilot’a şemayı atıp Power BI’a bağlamak bile bazen yeterli oluyor. Ama enterprise tarafındaysanız — ki Logosoft’taki müşterilerimizin %90’ı öyle — MCP yaklaşımı çok daha sağlıklı duruyor.
Peki neden?
Maliyet Tarafı: TL Bazında Düşününce
Bir de cüzdan kısmı var. NL2SQL serüveninin görünmeyen maliyeti token tüketimi. Şemayı her prompt’a koyarsanız ne oluyor? Diyelim orta büyüklükte bir şemanız var, 200 tablo. Şema açıklamalarıyla birlikte bu kolayca 30-40 bin token ediyor. Her kullanıcı sorgusunda bu yük tekrar gidiyor. Biraz can sıkıcı, evet.
Basit hesap yapalım: GPT-4o ile günde 1000 sorgu çalıştırırsanız, sadece şema yüzünden aylık ciddi bir tutar çıkıyor. Kur değiştikçe rakam oynar ama bazı projelerde altı haneli seviyeleri gördüm, şaka değil. MCP yaklaşımında modele yalnızca kullanılabilecek araçların listesi gidiyor; çok daha kompakt kalıyor. Bir telekom POC’unda token maliyetinin %70 düştüğünü ölçtük. Evet, gerçekten böyle öldü.
Sahada Karşılaştığım Tipik Hatalar
Şahsen, SQL MCP Server’ı ilk kurduğumda — geçen ay bir sigorta müşterisinde — şöyle bir hata aldım: DAB configuration not found. Sebep biraz aptaldı: dab-config.json dosyasının yolunu environment variable olarak set etmemişim. Microsoft dokümanında bu kısım bana göre biraz cılız geçilmiş. Neden önemli bu? Çözümü basit:
Ve işler burada ilginçleşiyor. Bu konuyla ilgili PyCon US 2026: Microsoft Standında Neler Olacak? yazımıza da göz atmanızı tavsiye ederim.
export DAB_CONFIG_FILE=/path/to/dab-config.json
# veya Windows tarafında:
$env:DAB_CONFIG_FILE = "C:\dab\dab-config.json"Bak şimdi, İkinci tipik hata authentication tarafında çıktı. MCP Server’ı Azure SQL’e bağlarken Managed Identity kullanmak istiyorsanız,
Eğer bu işe girecekseniz, benim önerim sırayı çok bozmadan gitmeniz: MSVC Build Tools v14.52 Preview: Mayıs 2026 Notları yazımızda bu konuya da değinmiştik.
- SQ L MCP Server’ı bu DAB üzerine bağlayın.
Peki Ben NL2SQL’e Karşı mıyım?
Eğer cevap “saatlerce süren yanlış karar, milyonlarca liralık zarar veya regülasyon cezası” işe klasik NL2SQL sizin işiniz olmayabilir.
Eğer cevap sadece “kullanıcı bir kez güler ve sayfayı yeniler” işe deneyebilirsiniz.
Peki neden olmasın?
Handoff Orchestration: Ajanlar Birbirine Topu Atınca Ne yazılarına da göz atın — dünyain bütününü görmek lazım.
Sıkça Sorulan Sorular
SQL MCP Server için Azure SQL şart mı?
Bi saniye — Hayır, şart değil. Aslında SQL MCP Server, Data API Builder üzerinden çalıştığı için on-prem SQL Server, Azure SQL Database, Azure SQL Managed Instance ve hatta PostgreSQL, MySQL gıbı farklı kaynaklara da bağlanabiliyor. E peki, sonuç ne öldü? Azure dışında kullanmak istiyorsanız Docker container olarak deploy etmek de bir seçenek — bence oldukça esnek bir yapı bu.
NL2SQL’de halüsinasyonu nasıl azaltırım?
İşin garibi, Tecrübeme göre üç yöntem işe yarıyor. Birinçisi, raw şema yerine view ve stored procedure’lar üzerinden erişim verin. İkincisi her sorguya bir “confidence check” katmanı ekleyin — yanı sonuç mantıklı mı diye kontrol eden ikinci bir prompt. Üçüncüsü işe kullanıcıya üretilen SQL’i göstermeden cevap dönmeyin. Şeffaflık halüsinasyonu tamamen önlemiyor, ama erken yakalamanızı sağlıyor — bu küçük fark aslında çok önemli.
Kullanıcılar SQL bilmiyorsa üretilen sorguyu göstermek mantıklı mı?
Açıkçası, SQL bilmeyen biri için o sorguyu göstermek sadece kafa karıştırır. Bunun yerine mesela şöyle bir özet sunun: “Bu cevabı şu mantıkla buldum: aktif olarak işaretlenmiş, son 30 günde işlem yapmış müşteriler.” Yanı SQL log’a yazılsın audit için, ama kullanıcıya sade bir doğal dil özeti gitsin. Hani teknik detayı saklayın, anlamı değil.
KVKK açısından NL2SQL’in riskleri neler?
Yanı, En büyük risk şu: modele veri akışı sırasında PII’nın kontrolsüz biçimde dış servisin loglarına düşmesi. Bu yüzden bence Azure OpenAI gıbı yerleşik bölge garantisi olan servisleri tercih etmek çok daha güvenli. Bir de şunu ekleyeyim — dynamic data masking ve row-level security’yi MCP katmanına değil, SQL katmanına koyun. Yanı derinlemesine savunma prensibi, güvenliği tek bir noktaya bırakmayın.
SQL MCP Server ücretli mi?
SQL MCP Server’ın kendisi açık kaynak ve ücretsiz. Ama tabii arkasındaki Azure kaynakları — mesela SQL Database, App Service, Azure OpenAI kullanıyorsanız o da — standart fiyatlandırmaya tabi. Tipik bir orta ölçekli kurulum için aylık 150-400 USD bandında bir Azure faturası bekliyebilirsiniz, kullanıma göre değişiyor. Bence başlamadan önce bir maliyet tahmini yapmak iyi ölür.
Kaynaklar ve İleri Okuma
Azure SQL Devblog: SQL MCP Server ve NL2SQL
Microsoft Learn: Data API Builder 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.
