Vanna text-to-SQL kütüphanesi açıklama yapılmadan arşivlendi, üretim kullanıcılarını göç planı bekliyor

Ne oldu

Doğal dilden SQL üretmek için yaygın biçimde kullanılan açık kaynak kütüphanesi vanna-ai/vanna, 29 Mart 2026'da sahibi tarafından arşivlendi. Ashish Sinha'nın dev.to'daki yazısına göre depo yaklaşık 23,8 bin yıldız biriktirmişti ve şu anda, değişikliğe dair sabitlenmiş herhangi bir açıklama olmaksızın salt-okunur durumda. Sinha, bakımcıların motivasyonları hakkında spekülasyon yapmayı bilinçli olarak tercih etmediğini, pek çok kullanıcının projeden ücretsiz olarak gerçek değer aldığını belirtiyor.

Salt-okunur olmanın pratikteki anlamı

İlk gün hiçbir şey bozulmaz: çalışan bir Vanna sürümüne sabitlenmiş bir uygulama çalışmaya devam eder. Son bulan şey, kodun çevresindeki her şeydir. Arşivlenen bir depo bağımlılık güncellemeleri almaz, bir sonraki veritabanı sürücüsü değişikliği geldiğinde düzeltme gelmez, güvenlik yaması gelmez; issue takipçisi ve pull request'leri kapatılır. Bu son nokta gizli bir maliyet taşıyor — normalde bir yorum dizisinde ortaya çıkacak olan geçici çözüm hiçbir zaman yazılamıyor.

Sinha, pratik ufuk açısından alttaki bir katmandaki bir sonraki kırıcı değişikliği işaret ediyor: SQLAlchemy, bir veritabanı sürücüsü ya da bir LLM SDK'sı. Tahmine göre bu tipik olarak yıllar değil aylar içinde gelir.

Vanna beş bileşendi, tek bir şey değil

Yazıya göre bir alternatif ararken düşülen tuzak, Vanna'nın birkaç farklı görevi tek çatıda toplamasıydı:

• DDL'lerinizi, dokümantasyonunuzu ve örnek SQL'lerinizi tutan bir training store
• Belirli bir soruyla ilgili şemayı seçen retrieval
• prompt birleştirme
• LLM çağrısı
• UI ve grafik yardımcıları

Bu beşini birden tek başına karşılayan, aktif olarak bakımı yapılan bir kütüphane yok. LangChain'in SQL agent'i ve LlamaIndex'in NLSQLTableQueryEngine'i ortadaki üçünü farklı tasarım yaklaşımlarıyla ele alırken, MCP tabanlı araç kutuları prompt birleştirme ve model çağrısını kapsıyor, training store ve retrieval'ı size bırakıyor.

Riskin bulunduğu yer: retrieval

Sinha'nın ayrıca üzerinde durduğu bileşen retrieval, çünkü modelin neyi görmesine izin verildiğine karar veren ve sorgu çalışmadan önce — dolayısıyla satır seviyesinde güvenlik, sanal özel veritabanları ya da başka herhangi bir politika katmanı devreye girmeden önce — çalışan kısım.

Tarif ettiği hata modu şöyle işliyor: kimlik farkındalığı olmayan bir retrieval katmanı, modele çağırıcının okuyamayacağı bir tablo veriyor. Model gayet geçerli bir SQL yazıyor, politika katmanı tüm satırları filtreliyor ve agent o müşteri için hiçbir sipariş olmadığını bildiriyor. Sonuç bir erişim reddi hatası değil, yanlış bir şeyi iddia eden inandırıcı bir cümle — okuyucu "bunu göremezsin" ile "böyle bir şey yok" birbirinden ayırt edemiyor. Hiçbir bileşen anomaliyi loglamıyor da, çünkü her biri görevini yerine getirdi. Bununla, temiz bir izin hatası üreten GRANT ile yanıltıcı cümle üreten satır seviyesinde güvenliği karşılaştırıyor.

Bir göç kontrol listesi

• Altta bir şey kaymadan önce, şimdi Vanna sürümünü ve geçici bağımlılıklarını sabitleyin.
• Beş parçadan hangilerini gerçekten kullandığınızı yazın — Sinha'ya göre çoğu ekip retrieval, prompt birleştirme ve LLM çağrısına güveniyor, UI yardımcılarına hiç dokunmamış.
• Training verisini dışa aktarın. O veri sizin, taşınabilir ve pahalı olan kısım.
• Kimliğin nerede devreye gireceğine karar verin: istek başına, retrieval'dan önce, çalıştırmadan sonra değil.
• Boş sonuç durumunu açıkça test edin. Kısıtlı bir kullanıcıya görmemesi gereken bir şey sorup agent'in ona ne söylediğini kontrol edin. Sinha bunu "kimsenin yapmadığı on dakikalık test" olarak adlandırıyor.

Açıklanmış bir alternatif

Sinha, yalnızca retrieval artı kimlik kapsamını kapsayan Apache-2.0 lisanslı bir proje olan schemagate'i kendisinin yazdığını açıklıyor ve bunun bir Vanna alternatifi olmadığını düz bir şekilde belirtiyor. Proje, kataloğu sıralamadan önce çağırıcı kimliğine göre filtreliyor; böylece kısıtlı bir tablonun adı hiçbir zaman prompt'a girmiyor; BM25 artı çevrimdışı bir hashed embedder kullanıyor, API anahtarı ve model çağrısı yok. Kasıtlı olarak dağınık bir 127 nesnelik şemada recall@6 değerini çıplak tanımlayıcılarla %47, Gemini 2.5 Pro tarafından yazılmış tablo açıklamalarıyla %60 ve Sonnet ile %80 olarak bildiriyor — çıkarımı, retrieval'ı yeniden inşa eden herkesin yalnızca embedding'lere değil, açıklama turuna da bütçe ayırması gerektiği.

Neden önemli

Bugün hâlâ çalışan arşivlenmiş bir kütüphane stabil değildir; bağımlılıklarındaki bir sonraki kırıcı değişikliği bekliyordur. Vanna'nın açıklamasız ortadan kayboluşu üretim kullanıcılarını bir sayaçla baş başa bırakıyor ve parçalara ayrılma sorunu, hazır bir halef olmadığı anlamına geliyor — ekipler beş ayrı yeteneği farklı araçlardan yeniden bir araya getirmek zorunda. Daha geniş açıdan bakıldığında, politika öncesi retrieval hata modu bakımı yapılsın ya da yapılmasın herhangi bir text-to-SQL sistemi için geçerli: şemayı seçen adım kimlik farkındalığına sahip değilse, izin reddedilmeleri hiçbir logun işaretlemeyeceği, kendinden emin yanlış cevaplara dönüşür.