Kodlama ajanına bir depo verilip veritabanını kendisinin seçmesi, sonra da seçtiğiyle geliştirme yapması istendiğinde ne çıkıyor ortaya? Armature’ın yayımladığı karşılaştırmada Azure SQL Database, Neon’un ardından ikinci sırada kaldı; Amazon RDS ve Supabase’in önünde. Microsoft’un Azure SQL Dev Corner blogunda Anna Hoffman’ın paylaştığı analiz, ajanların veritabanını hangi kriterlerle seçtiğini, Azure SQL Database’in nerede kazandığını ve nerede hiç masaya gelemediğini ele alıyor.
Armature testi nasıl kurgulandı?
Armature, gerçek kodlama ajanı CLI’larını (Claude Code, Codex, Cursor) sentetik ama gerçekçi altı depoya yerleştirdi, önce bir veritabanı seçmelerini, ardından o veritabanıyla gerçekten geliştirme yapmalarını istedi. Toplamda 356 çalıştırma tamamlandı, hepsi üç ayrı persona üzerinden yürütüldü:
- vibe coder
- junior developer
- senior engineer
Testin en güçlü yani şeffaflığı. Her oturum yayımlanmış durumda; promptlar, aramalar, çalıştırılan komutlar ve üretilen kod yeniden izlenebiliyor.
Sonuç tablosu
Neon seçimlerin %66,3’ünü aldı, Azure SQL Database’in payı %9,8 oldu. Birinci ile ikinci arasında ciddi bir fark var ama güçlü veritabanı seçeneklerinin bulunduğu bir listede ikincilik yine de dikkate değer. Amazon Aurora ve AlloyDB tabloda hiç görünmüyor.
Kazanımların tamamı senior engineer personasından geldi
Dağılım persona bazında keskin ayrışıyor. Azure SQL Database’in 35 kazanımının tamamı senior engineer personasından geldi. Junior developer personasında 106 çalıştırmanın 104’ünde Neon seçildi, 60 vibe coder çalıştırmasının tamamında da sonuç değişmedi.
Kaynak bunu şöyle yorumluyor: ajan yetenek bütünlüğü, işlem (transaction) bütünlüğü ve denetlenebilirlik üzerinden akıl yürüttüğünde Azure SQL Database öne çıkıyor. Hedef neredeyse tamamen en kısa sürede bir connection string’e ulaşmaksa diğer seçenekler avantajlı hale geliyor.
Bir çalıştırma özellikle öne çıkıyor. Görev, denetlenebilir bir envanter ve transfer API’siydi. Değerlendiricinin özeti şöyle:
Ajan; ilişkisel bütünlük, temporal system-versioned envanter denetimi ve mevcut Azure altyapısıyla uyum gerekçeleriyle Azure SQL Database’i önerdi. Ardından Azure SQL Database’i TypeORM, MSSQL migration’ları, seed servisleri, Bicep kaynak tanımları ve testlerle eksiksiz biçimde uyguladı; SQLite’ı ise açıkça eledi.
Marka bağlılığı olmayan bir ajan gereksinimlerden yukarı doğru akıl yürüttü, denetlenebilirlik için doğru cevap olduğu için temporal tables’ı seçti, sonra Bicep tanımlarını ve testleri de yazdı.
Farklı bir ölçüm, farklı bir sonuç
Latent Space Frontier AEO tracker başka bir soru soruyor. Ajanı bir depoya yerleştirmek yerine frontier modellere doğrudan “ne önerirsin?” diye soruyor.
- Managed Databases kategorisinde ilk tercih yanıtlarının %81’ini Neon alıyor. İkinci sırada Amazon RDS var. Azure SQL Database bu testte öne çıkan öneriler arasında yer almıyor.
- Databases kategorisinde (barındırma değil, motor seçimi) PostgreSQL 42 yanıtın %100’ünü alıyor. %90 değil, tamamı.
Bir tabloda ajanlar Azure SQL Database’i ikinci en popüler seçenek olarak seçip uyguluyor, diğerinde henüz varsayılan öneri bile değil. İkisi de gerçek bir şeyi ölçüyor, karar sürecinin farklı anlarını ölçüyorlar.
“SQL Server legacy” tezine karşı bir veri
Microsoft SQL ekibinin arka planında son yıllarda dolaşan “SQL Server legacy’dir” iddiasına Armature sonucu makul bir itiraz sunuyor, çünkü seçimi yapan tarafın ne nostaljisi var ne de bir satıcı ilişkisi. Gereksinimleri okudu, teknik gerekçelerle Azure SQL Database’i seçti.
İki tablo birlikte okununca görünen şu; Azure SQL Database gerçek gereksinimlere karşı değerlendirildiğinde iyi sonuç veriyor, sorun bu değerlendirmelerin daha fazlasına girememesi.
Ajanlar ne aradı?
Çalıştırmalar boyunca en çok tekrarlanan sorgulardan biri şu oldu:
site:learn.microsoft.com Azure SQL Database free offer 100000 vCore seconds 32 GB auto-pause free limit billingOn ayrı çalıştırma bu bilgiyi aradı. Başka bir sorgu ailesi doğrudan neon.com/pricing adresine yöneldi. Ajanlar gece 11’de bir geliştiricinin yaptığını yapıyor, faturalandırılıp faturalandırılmayacağını anlamaya çalışıyor. Bu cevabı en hızlı bulunur kılan taraf çalıştırmayı kazanıyor.
Anılmak ile seçilmek aynı şey değil
Armature verisindeki dönüşüm oranları ayrımı açıkça gösteriyor:
| Seçenek | Görünürlük | Seçilme |
|---|---|---|
| PostgreSQL | 356 çalıştırmanın 354’ünde anıldı | 0 kez seçildi |
| SQLite | 319 kez anıldı | 0 kez seçildi |
| Turso | 105 kez anıldı | 0 kez seçildi |
| Supabase | Çalıştırmaların %68’inde görüldü | %4 dönüşüm |
| Azure SQL Database | Çalıştırmaların %15’inde görüldü | %65 dönüşüm |
Kaynakta çalışmanın en cesaret verici sayısı olarak bu son satır gösteriliyor. Azure SQL Database konuşmaya girdiğinde ajanlar onu %65 oranında seçiyor. Ürün hikayesi güçlü, fırsat da bu hikayeyi daha fazla ajanın ve geliştiricinin kolayca bulmasını sağlamakta.
Bir uyarı var. Aynı isteğin farklı ifadelerle sorulması, 18 test vakasının 11’inde cevabı değiştirdi. Bu sonuçlar sabit doğa yasaları değil, değişkenler.
Microsoft tarafında ne yapılıyor?
Yazıya göre verideki fırsatlar halihazırda yürüyen çalışmalarla örtüşüyor ve üç başlık öne çıkarılıyor:
- Ücretsiz yolu görünür kılmak. Azure SQL Database free offer mevcut ve gerçekten ücretsiz; serverless auto-pause sayesinde boşta duran bir geliştirme veritabanı maliyet üretmiyor. Abonelik başına 10 ücretsiz veritabanına kadar kullanım mümkün.
- Kurulumu küçültmek. Kazanımların senior engineer tarafına yığılması, güçlü yeteneklerin zaten ne istediğini bilenler için net olduğunu gösteriyor. Provisioning, connection string ve ilk migration yolunu kısaltmak aynı değeri herkes için görünür kılabilir. Geliştirme ortamı izolasyonu da ajanların açıkça basit deneyim beklediği bir alan, bu konuda Private Preview aşamasındaki Azure SQL Database container’ı örnek gösteriliyor.
- Gerçekten okuyan okuyucu için yazmak. Dokümantasyon trafiğinin kayda değer bir bölümü artık, kod yazmaya devam edebilmek için dar bir soruya cevap arayan ajanlardan geliyor. Bu da iyi dokümantasyonun tanımını değiştiriyor: üst kısımda doğrudan cevaplar, çalıştırılabilir kod parçacıkları, sınırların ve kotaların açıkça belirtilmesi. Ajan odaklı araçlar tarafında duyuruların geleceği belirtiliyor, ayrıntı paylaşılmıyor.
O 35 çalıştırmayı kazandıran özellikler zaten kullanılabilir durumda: temporal tables, gerçek işlem garantileri, kurumsal hazırlık yetenekleri ve dayanıklı güvenlik varsayılanları. Kaynağa göre temel sağlam, sıradaki adım Azure SQL Database’in bu nitelikler üzerinden daha sık değerlendirilmesini sağlamak.
Kaynaklar ve İleri Okuma
- Coding agents are picking Azure SQL Database — Azure SQL Dev Corner (Anna Hoffman)
- Armature database leaderboard (356 çalıştırma, Ağustos–Eylül 2026)
- Latent Space Frontier AEO tracker — Managed Databases kategorisi
- Latent Space Frontier AEO tracker — Databases kategorisi (V5, Eylül 2026)
- Azure SQL Dev Corner blogu
- Azure SQL Foundations: Yeni Video Serisi ve GitHub Örnekleri
- Azure Accelerate for Databases: AI İçin Veriyi Hızlandırmanın Yeni Yolu
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.
İlginç bir test olmuş, ajanların Postgres yerine Azure SQL’e yönelmesi beklemediğim bir sonuç açıkçası. Acaba maliyet tarafını da hesaba katıyorlar mı, yoksa sadece teknik kriterlere mi bakıyorlar? Kendi projemde Claude Code hep Postgres öneriyordu, prompt farkı mı var merak ettim.
İlginç bir test olmuş, ajanların denetlenebilirlik gibi kriterlere bu kadar önem vermesi şaşırttı açıkçası. Ben Claude Code kullanıyorum, veritabanı seçimini genelde kendim yapıyordum ama artık ona da bırakıp denemek lazım. Bu arada şu yazınız da güzeldi: CppCon 2026’da Visual Studio: C++ İçin Ne Değişti?
Ajanların Postgres yerine Azure SQL’i seçmesi beni şaşırttı açıkçası, genelde açık kaynak tarafına yönelirler diye düşünürdüm. Acaba maliyet faktörü de değerlendirmeye dahil edilmiş mi, yoksa sadece teknik kriterler mi baz alındı?
İlginç bir test olmuş, ben ajanların hep Postgres’e yöneleceğini düşünürdüm açıkçası. Azure SQL’in denetlenebilirlik tarafının öne çıkması mantıklı ama merak ettim, maliyet faktörü de değerlendirmeye dahil edilmiş mi?