Moogo, her projeye kendi dosyasını veren barındırılan SQLite veritabanını başlattı

Moogo, Postgres'in önüne cilalı bir API koyma şeklindeki egemen DBaaS reçetesinden ayrılan bir barındırılan veritabanı servisi başlattı. Şirketin dev.to'daki duyuru yazısına göre her Moogo projesi kendi SQLite dosyasına sahip; bu dosyaya tamamen HTTP üzerinden ve bir API anahtarıyla erişiliyor — sürücü yok, bağlantı dizesi (connection string) yok, izlemesi gereken pool yok.

Proje başına bir dosya

Yazı, tasarımın hedef aldığı üç sorunu sıralıyor. Serverless fonksiyonların uzun ömürlü bir süreci olmadığı için geliştiriciler bağlantı havuzları kurmak ya da veritabanının önünde PgBouncer gibi bir pooler çalıştırmak zorunda kalıyor. Paylaşımlı çok kiracılı veritabanları, bir politikada eksik filtre yazıldığında başarısız olan satır düzeyi güvenlik politikalarına dayanıyor — şirket bunu ekosistemdeki en yaygın çok kiracılı ihlal deseni olarak tanımlıyor, ancak bu iddiayı destekleyecek bir veri sunmuyor. Ve uygulamaların büyük bir bölümü yalnızca birkaç tablo ve birkaç megabayttan oluşuyor; Postgres'in özellik listesinden çok güvenilirliğe ve hıza ihtiyaç duyuyorlar.

Moogo'nun yanıtı yapısal izolasyon: her sorgu ayrı bir dosyaya, ayrı bir dosya tanıtıcısıyla açılarak çalıştırılıyor ve fiziksel olarak başka bir projenin verisine erişemiyor. Filtrelenecek bir tenant_id yok, çünkü paylaşılan bir tablo yok. Yazma işlemleri ayrıca satır düzeyi güvenlik değerlendirmesini ve kiracılar arası dizin çekişmesini atlıyor; şirket hızın kaynağının bu olduğunu söylüyor.

Yalnızca prepared statement'lar

API yalnızca parametreli sorguları kabul ediyor: bir statement dizesi artı bağlı argümanlardan oluşan bir dizi. Değerler asla SQL metninin içinde taşınmıyor, dolayısıyla bir değer asla sözdizimine dönüşemiyor — yazı, bunun bu yolda SQL injection'ı yalnızca caydırmak yerine yapısal olarak imkânsız kıldığını iddia ediyor.

Her statement, çalıştırılmadan önce token'lara ayrılıp inceleniyor ve bazı işlemler tamamen reddediliyor: ATTACH, readfile, writefile, load_extension, üst üste bindirilmiş statement'lar ve trigger'lar. Trigger'lar bilerek reddediliyor, çünkü bir trigger gövdesi noktalı virgül içeriyor ve üst üste bindirilmiş statement'ları güvenilir şekilde tespit etmek gerçek bir parser gerektirirdi; şirket bunun yerine değişmez kuralların uygulama kodunda yazılmasını öneriyor. ATTACH reddediliyor çünkü yazma uç noktasını tüm sunucu için bir dosya okuyucusuna dönüştürürdü.

Anahtarlar, bütçeler ve üst sınırlar

Entegrasyon, moogo_ önekli bir anahtar ve bir URL'den oluşuyor. Projeler asla duraklamıyor — boşta kalma zaman aşımı yok, dolayısıyla tasarımın etrafından dolaşılacak bir soğuk başlangıç ya da açıklanacak yavaş bir ilk istek yok. Anahtarlar yalnızca bir kez, oluşturulurken ve döndürülürken gösteriliyor; sunucu yalnızca bir SHA-256 hash'i artı sekiz karakterlik bir önek saklıyor. Sonuç, yazının çerçevelediği gibi, sızan bir veritabanı dökümünün saldırgana çalışan anahtarlar listesi vermemesi ve bir anahtarın açığa çıkmasının diğerlerini ele vermemesi.

Her isteğin bir zaman bütçesi ve her projenin bir boyut üst sınırı var; ikisi de yanıtta döndürülüyor. Zorlama, iş tamamlanmadan önce yapılıyor: boyut sınırını aşacak bir yazma, kısaltılmak yerine tamamen reddediliyor.

Nelerden vazgeçiyorsunuz

Yazı sınırlamalar konusunda alışılmadık derecede açık. PostGIS sınıfı mekânsal destek yok, çünkü SQLite'ın R-Tree'si PostGIS değil. Bölgeler arası kopya (replica) yok, çünkü her proje tek bir sunucuda tek bir dosya olarak yaşıyor. Eşzamanlı analitik taramalar söz konusu değil, çünkü SQLite tek yazıcılı bir motor. Veritabanları 100 MB ile sınırlı ve bu sınır uygulanıyor. Proje anahtarı başına tek bir rol var, yani GRANT veya REVOKE yok. Self-hosting planlanıyor ama bu sürümde yok. Mevcut kademede hesaplara iki proje, veritabanı başına 100 MB ve proje başına 256 MB depolama düşüyor; henüz faturalandırma yok — her hesap aynı planda.

Neden önemli

Son yıllarda başlatılan hemen her managed database'in altında Postgres vardı, bu yüzden operasyonel tartışma havuzlama ve satır düzeyi güvenlik doğruluğu etrafında döndü. Moogo tersine iddiada bulunuyor: serverless fonksiyonlar, küçük SaaS ürünleri, dahili araçlar ve kalıcı belleğe ihtiyaç duyan AI agent'ları için, dosya-başına-proje izolasyonlu ve HTTP arayüzlü bir gömülü motor, bağlantı yönetimi, sürücü sürümleme ve politikaya dayalı çok kiracılılık gibi bütün iş kategorilerini yapılandırmayla değil yapıyla ortadan kaldırıyor. İddiaları satıcının kendi iddiaları; bağımsız testten değil bir duyuru yazısından geliyorlar ve 100 MB üst sınırı ile tek yazıcılı model sert kısıtlar. Ama DBaaS pazarında bir konum olarak bu gerçekten farklı bir bahis: izolasyonu politika doğruluğundan fiziksel ayrımaya taşıyın, en yaygın çok kiracılı hata modu, olması beklenen bir yapılandırma hatası olmaktan çıkıyor.