MSSQL Extension v1.43: Azure SQL’i VS Code’dan Kurmak Artık Mümkün
Bir sabah bilgisayarın başına oturup, tarayıcı açmadan, Azure portalına uğramadan, terminalde uzun az cli komutları yazmadan, dakikalar içinde çalışan bir Azure SQL veritabanına bağlandığınızı düşünün. Hatta işin içine para da girmiyor; cebinizden bir kuruş çıkmıyor. Kulağa biraz fazla iyimser geliyor, değil mi? Ben de ilk duyduğumda öyle baktım ama MSSQL extension’ın 1.43 sürümündeki yeni “provisioning” deneyimini kurcalayınca, açık konuşayım, fikir epey değişti.
Microsoft, VS Code için MSSQL eklentisinin Haziran sürümünde dört önemli özelliği ortaya koydu. Üçü artık GA (Genel Kullanıma Açık), biri Public Preview. Hepsine geleceğim ama önce şunu söyleyeyim: bu sürüm, “veritabanı geliştirme deneyimini editörün içine taşıyalım” fikrinin en elle tutulur adımlarından biri gibi dürüyor. Yıllardır SSMS, Azure Data Studio, portal ve VS Code arasında gidip gelen biri olarak söylüyorum — bu birleşme çabası fena değil, hatta uzun vadede baya iş görüyor.
Evet, doğru duydunuz.
Sürümün özeti: dört büyük başlık
Lafı uzatmadan, işin özünü bir tabloda toplayayım: (buna dikkat edin)
| Özellik | Durum | Ne işe yarıyor? |
|---|---|---|
| Azure SQL Database Provisioning | Public Preview | VS Code içinden, adım adım giden bir sihirbazla Azure SQL veritabanı açmanı sağlıyor |
| Schema Designer + GitHub Copilot | GA | Doğal dille şema kurma, değişiklikleri izleme, ORM script üretme gibi işleri toparlıyor |
| SQL Notebooks | GA | Jupyter tabanlı, çok çekirdekli SQL not defterleri sunuyor |
| Data API Builder + Copilot | GA | SQL’den REST, GraphQL ve MCP endpoint’leri üretmeyi kolaylaştırıyor |
Şöyle ki, Bunları biraz açacağım. Ama önce şunu söyleyeyim: provisioning tarafında ufak değil, baya hissedilen birkaç eksik var.
Evet.
Neyse uzatmayayım, tek tek bakalım. Çünkü tablo güzel dürüyor ama sahaya inince işler biraz değişiyor; özellikle VS Code içindeki akışta bazı yerler akıcı giderken, bazı yerlerde “hmm, burada niye böyle yapmışlar?” dedirtiyor (en azından benim deneyimim böyle)
Azure SQL Provisioning: VS Code’dan veritabanı, hem de ücretsiz
Şahsen, İşin en keyifli tarafı burada. Eklentinin “Deployments” sayfasına bir sihirbaz eklemişler, bak şimdi; Azure hesabınla giriş yapıyorsun, subscription’ı seçiyorsun, resource group’u ya seçiyorsun ya da yenisini açıyorsun, sonra sunucu ve veritabanı adını giriyorsun. Tek sayfa. Hepsi orada. Üstelik free tier ile başlaması bence asıl olay.
Araya gireyim: Free tier şu an aylık belli bir vCore-saat ve depolama limiti veriyor. Limit dolunca ne olacağına da sen karar veriyorsun: ya sistem otomatik pause moduna geçiyor. Takvim ayı dönene kadar bekliyor, ya da normal serverless tarifeden ücret yazmaya devam ediyor. İlginç, değil mi? Şey gibi dürüyor ama değil; bu seçim ekranı özellikle prototip çıkaranlar için bayağı mantıklı bir emniyet supabı olmuş.
Peki ne kadar pürüzsüz çalışıyor?
Açık konuşayım, ilk denemede authentication tarafında biraz tökezledim. Bilgisayarında birden fazla Azure tenant’ı tanımlıysa (danışmanlık yapan birçok arkadaşta bu durum var zaten), doğru tenant’a geçmek için ekstra bir adım atman gerekiyor. Bu bug değil tabiî, tasarım böyle. Ama akıcı mı? Eh, idare eder. İkinci denemede işler belirgin biçimde hızlandı.
Bir de şu var: provisioning bitince bağlantı otomatik olarak Connections paneline ekleniyor. Yanı sihirbazı kapattığın anda yeni veritabanın Object Explorer’da seni bekliyor oluyor. Küçük bir detay gibi görünüyor, ama bağlantı stringi kopyala-yapıştır işini ortadan kaldırdığı için valla işe yarıyor.
“Free tier + tek sayfa sihirbaz” kombinasyonu, Azure SQL ile tanışmak isteyen geliştiriciler için bugüne kadarki en düşük giriş engeli. Eğitim ve PoC senaryolarında bu çok değerli.
Türkiye’deki ekipler için ne ifade ediyor?
Sahada gördüğüm kadarıyla Türkiye’deki birçok küçük. Orta ölçekli yazılım ekibi Azure SQL’i denemek istiyor ama “ya yanlışlıkla bir kaynak açık kalırsa ve fatura uçar” korkusuyla geri çekiliyor. Free tier + auto-pause ikilisi tam bu psikolojik duvara çarpıp önü yumuşatıyor diyebilirim. Ayrıca öğrenciler ve bootcamp katılımcıları için de baya iş görüyor. Geçen sene bir eğitim verirken katılımcıların yarısı Azure trial credit’i bitirmiş gelmişti — şimdi en azından SQL tarafında o dert yok.
Şöyle ki, Kurumsal tarafta işe tablo biraz farklı. Büyük şirketlerde geliştiricilerin doğrudan kendi Azure subscription’larında veritabanı açma yetkisi çoğu zaman olmuyor; RBAC, policy, naming convention, tag zorunluluğu derken bu sihirbaz pek çok enterprise ortamda direkt çalışmaz. O yüzden bunu “kurumsal IT’yi devre dışı bırakacak bir şey” diye değil, “geliştiricinin sandbox subscription’ında hızlı prototip aracı” diye düşünmek daha doğru olur.
Schema Designer + GitHub Copilot artık GA
İtiraf edeyim, Schema Designer geçen yıl preview’da çıktığında, açık konuşayım, “yine bir tasarım aracı işte” diye geçirmiştim içimden. Yanılmışım. Bu sürümde Copilot entegrasyonu bayağı işe yarıyor, hatta beklediğimden fazla.
Mantık basit gibi dürüyor ama detayda güzel oynuyor: tasarım yüzeyini açıyorsunuz, tablolar orada dürüyor, sonra sohbet paneline “Müşteriler tablosuna doğum tarihi ve KVKK onay alanı ekle, bunlarla ilişkili bir audit_log tablosu oluştur” gibi bir şey yazıyorsunuz. Copilot değişiklikleri öneriyor, Change Tracking panelinde her ekleme, silme. Değiştirme ayrı ayrı listeleniyor; beğenmediğinizi de tek tıkla geri alabiliyorsunuz. Kulağa küçük geliyor, ama elle şema kuran biriyseniz farkı hemen hissediyorsunuz.
İşin asıl iyi tarafı burada çıkıyor. Tasarımdan ORM-ready migration script üretebiliyorsunuz. Yanı Entity Framework ya da Dapper kullanan bir projeye doğrudan taşınması kolay çıktılar alıyorsunuz; lafı gevelemeden söyleyeyim,.NET tarafında çalışan ekipler için bayağı rahatlatıcı bir nokta bu. Hatta bazen insan “keşke bunu daha önce görseydim” diyor (evet, doğru duydunuz)
Evet, doğru duydunuz.
Beni rahatsız eden bir nokta
Şahsen, Copilot’un önerdiği şemalar bazen fazla “ders kitabı” gibi kalıyor, hmm nasıl desem, biraz steril. Her tabloya CreatedAt, UpdatedAt, DeletedAt eklemek istiyor; naming convention da bazen camelCase ile PascalCase arasında gidip geliyor. Yanı üretilen şemayı gözünüzü kapatıp kabul edemiyorsunuz — review şart. Ama hızlı taslak çıkarmak için? Evet, idare eder.
SQL Notebooks: Jupyter mantığı SQL’e geliyor
SQL Notebooks bence pek konuşulmayan ama baya iş görecek özelliklerden biri. Hani veriyle uğraşırken iki sorgu çalıştırıp (söylemesi ayıp) araya not düşmek istersiniz ya, işte tam o akış şimdi VS Code içinde, Jupyter defteri gibi ilerliyor. Markdown hücreleri var, SQL hücreleri var, sonuç tabloları da aynı dosyada dürüyor; dağılmadan gidiyorsunuz.
Bunu biraz açayım.
Güzel tarafı şu: multi-kernel desteği sayesinde aynı not defterinde farklı bağlantılara karşı sorgu atabiliyorsunuz. Peki neden önemli? Çünkü prod ile dev’i yan yana koyup bakmak, ya da iki veritabanı arasında veri sağlığı kontrolü yapmak gerektiğinde, tek ekranda işi toparlamak gerçekten rahatlatıyor; üstelik sonuçları düzgün gösteriyor ve dışarı aktarabiliyorsunuz.
Kimler için mantıklı?
- Veri analistleri için: Power BI’a girmeden hızlı keşif (bence en önemlisi)
- DBA’ler için: Tekrarlanan sağlık kontrolleri tek dosyada
- Eğitmenler için: Açıklamalı SQL ders materyalleri
- Postmortem yazanlar için: Sorgu + sonuç + yorum tek yerde
Bi saniye — Burası biraz ilginç. Bu yapı aslında Azure Data Studio’da gördüğümüz bir özelliğin VS Code tarafına taşınmış hali gibi dürüyor. Microsoft’un Azure Data Studio’yu yavaş yavaş kenara çekip işleri VS Code’a topladığını (yanlış duymadınız). Biliyoruz; açık konuşayım, bu sürüm de o yön değişiminin net bir parçası oluyor. Evet.
Data API Builder + Copilot: Şemadan API’ye tek tıkla
İnanın, Data API Builder, hani bir süredir ortalıkta dolaşıyordu ya, işte bu sürümde Copilot entegrasyonuyla genel kullanıma açıldı. Mantık da aslında çok düz: SQL veritabanını gösteriyorsun, hangi tabloyu ya da view’i dışarı açacağını seçiyorsun, sonra DAB sana REST, GraphQL. MCP endpoint’lerini hazırlıyor. Kulağa biraz sihir gibi geliyor, ama öyle uçuk bir tarafı da yok.
Açıkçası, MCP kısmı işe ayrı bir hikâye. Model Context Protocol artık Microsoft ekosisteminde sağa sola yayılıyor; veritabanını bir MCP server arkasına koyduğunda, Copilot Chat ya da başka bir LLM ajanı bu veriyi tool gibi kullanabiliyor. Aslında dur — şöyle söyleyeyim: AI ajanlarının “şirket veritabanına soru sorabilmesi” için artık her seferinde özel kod yazman gerekmiyor. DAB ile MCP yan yana gelince iş baya toparlanıyor.
Hmm, bunu nasıl anlatsamdı…
Kolon seviyesinde kontrol şart
Yeni Copilot yardımcısı, hangi tabloları yayınlayacağını sorarken kolon bazında filtre vermene de izin veriyor. Yanı Customers tablosunu açıp TaxNumber veya NationalID kolonlarını dışarıda bırakabiliyorsun; güzel tarafı burada ortaya çıkıyor. KVKK ve GDPR tarafında bu küçük detaylar var ya, bazen bütün oyunu değiştiriyor. Bunu config dosyasından elle yapmak mümkündü tabiî, ama görsel arayüzle gelmesi işi ciddi biçimde rahatlatıyor.
Burada bir uyarı var: otomatik üretilen endpoint’leri asla auth olmadan production’a açma. Varsayılan template bazen geliştirme için gevşek ayarlarla gelebiliyor, yanı ilk bakışta masum dürüyor ama sonra baş ağrıtıyor. Yayına almadan önce config dosyasındaki authentication ve authorization bloklarına büyük ihtimalle bak; atlama bunu.
Uçtan uca senaryo: bir mikroservisi nasıl ayağa kaldırırım?
Bu dört parçayı yan yana koyunca kafamda tek bir akış oluştu, hani o ilk bakışta biraz dağınık duran ama sonra yerine oturan akışlardan biri. Bir yandan hızlısın, bir yandan da sürekli sekme değiştirip yorulmuyorsun.
Bir dakika — bununla bitmedi.
- Provisioning sihirbazı ile free-tier Azure SQL veritabanı oluştur (2-3 dakika) (bu kritik)
- Schema Designer‘ı aç, Copilot’a domain’i anlat, taslak şemayı al, review et, deploy et (15-20 dakika)
- SQL Notebook ile birkaç örnek veri ekle ve sorgularını test et (10 dakika)
- Data API Builder ile REST + GraphQL endpoint’lerini üret, auth ekle, test et (15 dakika)
Lafı gevelemeden söyleyeyim; toplamda yaklaşık 45 dakikada çalışan bir back-end çıkıyor. Evet, bu daha önce de yapılabiliyordu. Ama aynı hızda değil, aynı rahatlıkta hiç değil; araçlar arasında gidip gelmekten insanın dikkati dağılıyordu, şimdi işe VS Code içinde kalıp işi bitirebiliyorsunuz.
İlginç olan şu ki, Peki neden önemli? Çünkü mesele sadece “hız” değil. Asıl fark, provisioning’den şema tasarımına, test verisinden API katmanına kadar olan yolun tek editör içinde toparlanması; açık konuşayım, bu küçük gibi görünen şey pratikte baya iş görüyor.
Benzer bir entegrasyon yaklaşımının diğer veritabanı tarafında nasıl şekillendiğini merak edenler için VS Code’da PostgreSQL Performans Ayarı: Artık Tek Ekran yazısı iyi bir karşılaştırma noktası. Microsoft hem MSSQL hem PostgreSQL eklentilerinde aynı çizgiyi izliyor — geliştirici deneyimini editörün içine topluyor. Şey gibi düşünün; ayrı araçları kovalamak yerine işi tek yerde tutuyorsunuz.
Eksik bulduğum noktalar
Size bir şey söyleyeyim, Her şey toz pembe değil. Bazı dertler hâlâ dürüyor, hatta bazıları ilk bakışta küçük görünse de işin içine girince can sıkabiliyor:
- Custom rol yok: Provisioning sihirbazı şu an Contributor seviyesinde yetki istiyor. Daha kısıtlı rollerle çalışan ekiplerde bu baya sorun çıkarabilir, çünkü herkesin eline geniş yetki vermek istemiyorsunuz.
- Private endpoint desteği zayıf: Free tier zaten public geliyor, ama paid tier’a geçince private endpoint kurulumu için yine portala gitmeniz gerekiyor. Hani otomasyon var sanıyorsunuz, sonra bir bakıyorsunuz yarım kalmış; işte biraz öyle.
- Tag zorunlu olan ortamlarda kullanışsız: Sihirbaz tag girme arayüzü sunuyor ama “minimum N tag zorunlu” policy’sine takılırsanız hata mesajı çok bilgilendirici değil. Açık konuşayım, burada kullanıcıya biraz daha net yol gösterebilirdi. (bu kritik)
- Multi-region failover yok: Tek bölgede tek veritabanı kuruluyor. Bu bir prototipleme aracı, production değil — bunu unutmamak lazım. Evet, tam da mesele bu.
Yanı şöyle özetleyeyim: kağıt üstünde süper dürüyor, pratikte işe biraz bekleyip görmek lazım. Hele bir de Azure tarafındaki diğer otomasyon araçlarıyla (mesela azd 1.26 Geldi: tool, exec ve Multi-Layer Provisioning Notları yazısında anlattığım azd CLI ile) entegrasyonun nasıl gelişeceğini ben de merak ediyorum; çünkü asıl oyun orada başlayacak gibi, yoksa tek başına güzel görünen şeyler çok öldü.
Hangi senaryoda hangisi mantıklı?
Sık gelen soruya net cevap vereyim: “Bu sürümü kim, ne zaman kullanmalı?” Peki neden? Çünkü herkesin ihtiyacı aynı değil,. Açık konuşayım, bazen araçtan çok kullanım şekli belirliyor sonucu. Küçük bir ekipteyseniz iş görür; büyük yapıda işe biraz daha temkinli gitmek gerekiyor.
İtiraf edeyim, Küçük ekip / freelancer / öğrenci iseniz: Hemen kurun, free-tier veritabanı açın, Schema Designer ile biraz oynayın (yanlış duymadınız). Hiçbir şey kaybetmezsiniz. Hatta öğrenme tarafında baya iş görüyor, çünkü elinizle kurcaladıkça mantığı daha çabuk oturtuyorsunuz (ve evet, bu tür denemeler bazen dokümantasyondan daha hızlı öğretiyor). Mantıklı değil mi? Evet.
Orta ölçekli yazılım şirketinde geliştiriciyseniz: Schema Designer ve SQL Notebooks’u günlük rutininize alın (kendi tecrübem). Provisioning’i sandbox subscription’da kullanın, ama production veritabanlarını yine IaC (Bicep/Terraform) ile yönetin. Bak şimdi, burada küçük bir ayrım var: geliştirme tarafında hız kazanmak istiyorsunuz, ama canlı ortamda kontrolü bırakmak istemezsiniz; ikisini karıştırınca işler çorba olabiliyor. Neyse uzatmayalım, denge bu.
Araya gireyim: Enterprise/banka/telekom düzeyindeyseniz: Provisioning sihirbazını şu aşamada güvenlik politikalarınız büyük ihtimalle reddedecektir. Ama Schema Designer ve DAB özellikleri, geliştiricilerinizin verim artışı için değerli. Sadece üretilen artefaktları (script, config) Git’e koyup standart review süreçlerinizden geçirin. Az önce “reddeder” dedim ya, aslında mesele araçtan çok uyum meselesi; yanı platform iyi olabilir ama sizin onay zinciri başka türlü çalışıyordur. Sız ne dersiniz?
Pratik kurulum adımları
Başlamak istiyorsanız, işin sırası aslında net. Biraz dağınık görünüyor, evet, ama ilk kez yapan biri için bu akış baya iş görüyor.
# 1. VS Code'da extension'ı kur (veya güncelle)
code --install-extension ms-mssql.mssql
# 2. Komut paletinden Azure'a giriş yap
# Ctrl+Shift+P -> "MSSQL: Sign in to Azure"
# 3. Activity Bar'dan MSSQL ikonuna tıkla
# 4. "Deployments" sekmesine geç
# 5. "Create Azure SQL Database (Preview)" seçeneğini seç
# 6. Sihirbazı takip et
Şöyle ki, Bağlantı tamamlandıktan sonra Object Explorer’da veritabanınız görünüyor. Sağ tıklayıp “Open Schema Designer” diyerek tasarım ekranına geçebiliyorsunuz; ama burada küçük bir dipnot var, AI yardımı istiyorsanız Copilot eklentisinin de yüklü ve aktif olması lazım, yoksa o kısım boşta kalıyor gibi oluyor (ben de ilk duyduğumda şaşırmıştım)
Sıkça Sorulan Sorular
Azure SQL free tier ne kadar süre ücretsiz?
Aslında sürekli ücretsiz, yanı bir son tarihi yok. Ama aylık vCore-saat ve depolama limitleri var. Limit dolunca iki seçeneğin var: ya otomatik pause moduna geçiyor (ücretsiz kalmaya devam ediyor. O süre erişemiyorsun) ya da standart serverless tarifesiyle ücretlendirme başlıyor — seçim büyük ölçüde sana kalmış. Bir de şunu söyleyeyim: bu hak hesap başına sadece bir database için geçerli.
Schema Designer ile üretilen migration script’lerini production’da kullanabilir mıyım?
Teknik olarak evet. Ama bence önce mutlaka bir gözden geçirme şart. Üretilen script’leri dev ortamda test et, indeksleme ve constraint kararlarının mantıklı olduğundan emin ol, sonra standart CI/CD pipeline’ından geçirerek production’a al. Açıkçası otomatik üretilen her şeyi gözü kapalı uygulamak riskli — tecrübeme göre küçük bir review büyük sorunların önüne geçiyor.
Data API Builder ile üretilen endpoint’ler production-ready mi?
Authentication ve authorization katmanlarını kendin yapılandırdığın sürece evet. Varsayılan template geliştirme amaçlı, hani genellikle “anonymous” erişime izin veriyor. Production’a almadan önce dab-config.json dosyasındaki authentication bloğunu Azure AD veya JWT ile sağlamlaştırman gerekiyor — bunu atlama.
SQL Notebooks’u Git’te versiyonlayabilir mıyım?
Evet. .sqlnb uzantılı dosyalar JSON tabanlı olduğu için Git’te tutulabiliyor. Ama şunu söyleyeyim, mesela Jupyter not defterleri gibi diff’leri pek okunaklı değil. Bence code review için not defterini önce HTML veya Markdown’a export etmek çok daha pratik.
Bu özellikler Azure Data Studio’da da olacak mı?
Hayır. Microsoft, Azure Data Studio’yu 2026 sonuna doğru (söylemesi ayıp) emekliye ayırıyor. Yeni geliştirmelerin tamamı VS Code’a yönlendiriliyor. Yanı şu an Azure Data Studio kullanıyorsan, açıkçası kademeli olarak VS Code + MSSQL extension geçişini planlamaya başlamanı öneririm — ne kadar erken o kadar iyi.
Kaynaklar ve İleri Okuma
Azure SQL DevBlog: MSSQL Extension for VS Code v1.43 Duyurusu
Microsoft Learn: MSSQL Extension Resmî Dokümantasyonu
Microsoft Learn: Data API Builder Genel Bakış
Azure SQL Database Free Offer Detayları
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.
3 comments