Şubat 2026 yaklaşırken gelen kutuma aynı soru düşmeye başladı: “Aşkın bey, Azure Data Studio gerçekten kapanıyor mu?” Kapanıyor. Microsoft 28 Şubat 2026’da fişi çekiyor ve önerilen yol da net: VS Code + MSSQL eklentisi (ciddiyim). Bunu duyunca bazı arkadaşlar yine “yine mi göç” diye söylendi, haklılar biraz (buna dikkat edin). Ama bu sefer işin rengi farklı, önü birazdan açacağım.
Şunu fark ettim: Bu yazıda lafı dolandırmadan, kendi geçiş tecrübemi. Bir bankacılık projesinde 14 kişilik DBA/dev ekibini ADS’den VS Code’a nasıl taşıdığımızı anlatacağım. Hangı tuzaklar can sıkıyor, hangı ayarlar atlanınca sabah 9’daki standup’ta sürat asılıyor — hepsi var içinde.
Önce şunu net konuşalım: Neden ADS gidiyor?
Microsoft tarafının resmî açıklaması kabaca şu: kaynakları tek bir yere toplamak istiyorlar, yanı VS Code’a. Açıkçası ben bunu mantıklı buluyorum. ADS zaten VS Code’un bir fork’uydu; iki ürünü paralel beslemek hem ekibi yoruyordu hem de kullanıcıyı ikiye bölüyordu. Ben uzun zamandır SQL işlerimde zaten VS Code kullanıyordum, ADS’yi daha çok eski projeler için açıyordum. O yüzden bana bu karar biraz “beklenen son” gıbı geldi.
Gel gelelim herkes benim gıbı düşünmüyor (şaşırtıcı ama gerçek). Türkiye’deki kurumsal müşterilerde gördüğüm tablo şu: DBA tarafı ADS’ye alışmıştı, çünkü SSMS’in Mac/Linux sürümü yok ve ADS bayağı iyi bir ara çözüm olmuştu (ben de ilk duyduğumda şaşırmıştım). Şimdi onlardan VS Code’a geçmelerini istiyoruz. Bu sadece editör değiştirmek değil; alışkanlık değiştiriyorsunuz. F5 ile sorgu çalıştırma, Object Explorer benzeri ağaç yapı, Notebook kullanımı (şaşırtıcı ama gerçek). hepsinin yeni karşılığını öğrenmek gerekiyor.
Bir dakika — bununla bitmedi.
“VS Code’a geçtikten sonra fark ettim ki ADS’de eksik sandığım şeylerin bir kısmı aslında burada varmış; Copilot, Dev Containers, Git entegrasyonu… Meğer ben başka pencerede oturuyormuşum.” — Geçen ay bir müşteride yaptığım workshop’taki kıdemli DBA’in sözleri.
10 dakikalık göç: gerçekten 10 dakika mı?
Microsoft bloğunda “10 dakikada geçiş” diyor. Pratikte? Tek başınıza çalışan bir geliştiriciyseniz ve sadece sorgu çalıştırıyorsanız evet, on dakikaya yakın sürer (kendi tecrübem). Ama SQL Database Projects, CI pipeline’ları, özel keymap’ler devreye girince süre bir anda uzuyor; ben açık konuşayım, bazen 1-2 saati buluyor (yanlış duymadınız)
İşin aslı şu: geçişin kendisi hızlı, alışmak işe uzun sürüyor.
Kurulum sırası — bu sırayı bozmayın
Şunu söyleyeyim, Geçen hafta bir müşteride şahit öldüm; genç bir geliştirici önce SQL Database Projects’i kurmuş, sonra.NET SDK’yı yüklemiş, en son MSSQL’e geçmişti (inanın bana). Build hata verince “VS Code bozuldu” diye panikledi. Halbuki sıra önemliymiş. Şöyle gidin:
- .NET 8 SDK — önce bu.
dotnet --versionile doğrulayın. Yoksa SQL Database Projects ilk build’de patlıyor. — ciddi fark yaratıyor - MSSQL eklentisi — VS Code Marketplace’te “SQL Server (mssql)” diye arayın. Microsoft’un yayınladığı olanı seçin, klon olanları değil. — ciddi fark yaratıyor
- SQL Database Projects — “SQL Database Projects” diye arayın. Bunu MSSQL’in yan ürünü gıbı düşünün.
- MSSQL Database Management Keymap — F5 ve diğer ADS kısayolları için lazım oluyor.
ADS Migration Toolkit: işin can damarı
MSSQL eklentisinin içinde “ADS Migration Toolkit” diye bir akış var. Bana sorarsanız bu özelliğin hakkı yeterince verilmemiş. Ne yapıyor? Kayıtlı bağlantılarınızı, bağlantı gruplarını, ayarları ve kısayolları VS Code’a taşıyor. Tek tıkla bitiyor işte.
Eh, Bunu ilk denediğimde açık konuşayım biraz şüpheliydim (inanın bana). “Microsoft’un migration tool’u” deyince aklıma SSMA’nın o eski çatırdayan günleri geliyor; şey gıbı yanı insan temkinli oluyor ister istemez. İşte, ama bu sefer fena değilmiş, baya iş görüyor. 47 bağlantısı olan bir ekip arkadaşımızın setup’ını yaklaşık 30 saniyede taşıdık; sadece Azure AD bağlantıları için yeniden token almak gerekti, gerisi geldi gitti.
Şimdi gelelim işin can alıcı noktasına.
F5 problemi: kaş hafızasını kaybetmeyin
F5 olmadan SQL geliştiricisinin eli ayağı şaşıyor resmen. VS Code’da varsayılan olarak F5 “Debug Start” yapıyor; yanı SQL sorgusu çalıştırmıyor. Bunu çözmenin yolu MSSQL Database Management Keymap eklentisini kurmakta yatıyor. Kurar kurmaz F5 = “Run Query”, Ctrl+Shift+E = “Execute Selection” oluyor; yerini buluyor yanı. Daha fazla bilgi için Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımıza bakabilirsiniz.
Ben buna ekstra olarak Ctrl+K Ctrl+R kombinasyonunu “Cancel Query”ye atadım çünkü uzun süren sorgularda hayat kurtarıyor (ADS tarafında bunun karşılığı yoktu). keybindings.json dosyanıza şunu ekleyin: Bu konuyla ilgili Azure DevOps Git Policy API: 10-15 Kat Hız Geldi yazımıza da göz atmanızı tavsiye ederim.
{
"key": "ctrl+k ctrl+r",
"command": "mssql.cancelQuery",
"when": "editorTextFocus && editorLangId == 'sql'"
}
SQL Database Projects: asıl oyun burada
Sorgu çalıştırmak işin küçük kısmı aslında; yüzde yirmi diyelim belki de daha azına denk geliyor bazen. Ciddi ekiplerde mesele şema değişikliklerini code review’dan geçirmek, CI’da doğrulamak ve prod’a güvenle deploy etmek oluyor. SQL Database Projects bunu sağlıyor — yanı schema as code mantığıyla ilerliyorsunuz. Daha fazla bilgi için Yeni GitHub PR Dashboard: Artık Varsayılan Geliyor yazımıza bakabilirsiniz. Daha fazla bilgi için Kubernetes v1.36’da User Namespaces GA: Rootless Devri Geldi yazımıza bakabilirsiniz.
Şöyle düşünün: tablolarınız, prosedürleriniz, view’larınız hepsi .sql dosyaları olarak repoda duruyor ya hani; pull request açıyorsunuz ve takım arkadaşı diff’e bakıp “şu kolon neden nullable öldü?” diye sorabiliyor (iyi de soruyor). Build sırasında syntax hatası varsa pipeline kırılıyor. Publish’e bastığınızda işe VS Code size deploy edilecek T-SQL’i önce gösteriyor; siz onaylamadan hiçbir şey çalışmıyor. Bu son kısım önemli ama birazdan nedenini anlatacağım.
İlk build: temiz çıkmazsa devam etmeyin
Yeni bir SQL projesi oluşturduğunuzda ya da eski DACPAC projesini açtığınızda ilk işiniz build almak olsun dedim mi? Dedim sayın artık bunu çünkü gerçekten öyle olması gerekiyor.
Build başarılı çıkmıyorsa publish hayal ölür. Ben kuralı şöyle koydum: ilk gün sadece build var, deploy yok var yanı yok değil ama dokunulmuyor daha fazla karıştırmayın işi derim ben de.
Kısa bir not düşeyim buraya. Cosmos DB Maliyet Optimizasyonu: AI Yüklerinde 7 Taktik yazımızda bu konuya da değinmiştik.
Eğer build size “dotnet not found” benzeri bir hata veriyorsa.NET SDK PATH’e eklenmemiş olabilir; çoğu zaman sistem yeniden başlatınca düzeliyor zaten. Bazen inat ediyor tabii ki kolay ölmüyor her şey.
Maç tarafında işe /usr/local/share/dotnet‘i ~/.zshrc‘ye eklemeniz gerekebilir.
Publish dialog: güvenli deploy’un kalbi
Aslında, P roje panelinden projenize sağ tıklayın ve “Publish” deyin.
Bir dialog açılıyor:
- Hedef sunucu/veritabanı seçimi (Azure SQL DB, Azure SQL MI, on-prem SQL Server, Fabric SQL DB)
- Create Profile / Publish profile; bunları XML olarak kaydedip repoda tutabiliyorsunuz (prod/staging/dev için ayrı profiller yapmak mantıklı)
- “Generate Script”, bence en kıymetli özellik bu kısmın ta kendisi
“Generate Script” dediğinizde VS Code arka planda mevcut DB’nın durumunu okuyor, sizin projeyle karşılaştırıyor ve tam olarak hangı T-SQL’in çalışacağını önünüze koyuyor.
Hiçbir şey deploy etmeden yapıyor bunu.
Bu önizleme beni iki kez prod kazasından kurtardı; bir keresinde ekranda “DROP COLUMN” görünce paniklemiştik çünkü kolon adını yanlış yazmışım.
Önizleme olmasa data uçup gidecekti.
Türkiye’deki kurumsal yapılar için pratik tavsiyeler
Küçük bir sapma yapayım şimdi — orijinal blogdaki düz akıştan biraz çıkıyorum. Türkiye’deki şirketlerde bu geçişi nasıl planlamak lazım ona değinmeden olmaz.
Çünkü bizim tarafta dinamikler biraz farklı ilerliyor hani.
Oops need valid html only.
Sıkça Sorulan Sorular
Azure Data Studio Şubat 2026’dan sonra da çalışır mı?
Teknik olarak evet, kurulu olan ADS açılmaya devam ediyor. Ama Microsoft artık güncelleme, güvenlik yaması ya da yeni Azure servis desteği vermiyor. Yanı mesela yeni bir SQL Server sürümü geldiğinde ADS önü desteklemeyebilir. Açıkçası production ortamında kullanmaya devam etmenizi hiç önermem.
SQL Database Projects için neden.NET 8 SDK gerekiyor?
Bence, SQL Database Projects, MSBuild altyapısı üzerine kurulu. Build aşamasında DAC framework ile T-SQL’i derliyor ve bu süreç.NET runtime’a ihtiyaç duyuyor..NET 8 aslında LTS bir sürüm, 2026 Kasım’a kadar destekleniyor — bence uzun vadede güvenli bir seçim.
Mevcut ADS notebook’larım kaybolacak mı?
Hayır, kaybolmuyor. .ipynb dosyaları standart Jupyter formatında ve VS Code Polyglot Notebooks eklentisiyle açılıyor. Sadece SQL kernel’i manuel seçmeniz gerekiyor. Hani magic command’ler ve bazı özel görselleştirmelerde küçük uyumsuzluklar çıkabiliyor, onları elle düzeltmek lazım.
VS Code’a geçince Copilot için ekstra ödeme yapmam gerekiyor mu?
GitHub Copilot aboneliğiniz yoksa evet, ayda 10 USD bireysel plan ya da Business plan gerekiyor. Ama Copilot olmadan da MSSQL eklentisi gayet sorunsuz çalışıyor, yanı sadece AI yardımından mahrum kalıyorsunuz. Bireysel kullanıcılar için “Copilot Free” planı da var — ayda 50 chat hakkı ile başlangıç için yeterli bence.
Linux ve Maç’te de aynı şekilde mi çalışıyor?
Evet, MSSQL eklentisi cross-platform. Ben günlük olarak Maç’te kullanıyorum, ekip arkadaşlarımdan biri de Ubuntu’da kullanıyor. Sadece.NET 8 SDK kurulumu platforma göre değişiyor — Maç’te brew ile, Linux’ta apt veya tarball ile. Performans farkı yok; tecrübeme göre Linux’ta build hafif daha hızlı geliyor.
Kaynaklar ve İleri Okuma
Bunu yaşayan biri olarak söyleyeyim, Azure SQL Blog: Move Your Azure SQL Workflow to VS Code — Iqra Shaikh tarafından yazılan resmî geçiş rehberi, orijinal kaynak.
MSSQL Extension Resmî Dokümantasyonu — Microsoft Learn üzerindeki tam referans, tüm komutlar. Ayarlar burada.
SQL Database Projects Dokümantasyonu — Şema as code yaklaşımı, publish profilleri. CI/CD entegrasyonu için detaylı rehber.
vscode-mssql GitHub Reposu — Eklentinin açık kaynak deposu, issue açmak ve roadmap’i takıp etmek için ideal yer.
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.



