WebDB, TypeScript'ı doğrudan bytecode'a derleyen 19 KB'lık ilişkisel sorgu motorunu yayınladı

Tarayıcı için yazılmış, tarayıcıya taşınmamış bir ilişkisel motor

Geliştirici Ahmad Moussawi, WebDB'yi yayınladı; masaüstü veritabanından derlenmek yerine özellikle tarayıcı için inşa edilmiş bir ilişkisel veritabanı motoru. 6 Kasım'da dev.to'da yayımlanan yazıda Moussawi, projeyi offline-first geliştiricilerin genellikle izlediği iki yoldan bir kaçış olarak konumlandırıyor: ilişkisel olmayan ham IndexedDB ya da SQLite ve PGlite gibi masaüstü motorlarının WebAssembly build'leri — ki bunlar kolaylığı büyük indirme boyutları ve kullanışsız hosting gereksinimleriyle takas ediyor.

İsmine rağmen WebDB bir tarayıcı API'si değil. Yazarın göre gzip sonrası yaklaşık 19 KB (yaklaşık 51 KB ham) ağırlığında bir WebAssembly çekirdeğine sahip bir JavaScript kütüphanesi — tipik SQLite veya Postgres WASM portlarından yaklaşık %95 daha küçük — ve saf bir JavaScript fallback ile geliyor.

Sorgu yolunda SQL string'i yok

Merkezi tasarım tercihi SQL metnini tamamen bırakmak. Masaüstü veritabanları, sorgular ağ soketi üzerinden string olarak geldiği için bir SQL parser'a ihtiyaç duyar; tarayıcı sekmesinde ise uygulama ve veritabanı aynı runtime'ı paylaşır, dolayısıyla Moussawi'ye göre bir sorguyu SQL'e serileştirip sonra tekrar bytecode'a tokenize etmek boşa harcanan bir çabadır.

WebDB bunun yerine akıcı ve tipli bir TypeScript query builder'ı doğrudan sanal makinesinin çalıştırdığı binary opcode'lara derliyor — yazıda OP_INDEX_SCAN ve OP_RESULT_ROW gibi instruction'lardan bahsediliyor — yazarın belirttiğine göre 0,05 ms'nin altında bir sürede. Bundle'a dahil edilecek bir C lexer veya parser olmadan motor yine de B+Tree index'leri, join'ler, aggregate'ler, subquery'ler ve ACID transaction'lar sunuyor.

Tasarım ayrıca bir sunucu yapılandırma sorununu da aşılıyor gibi görünüyor. SQLite tabanlı WASM kurulumları genellikle hızlı senkron erişim için SharedArrayBuffer ister; bu da üçüncü taraf script'leri, embed'leri ve kimlik doğrulama popup'larını bozabilen COOP ve COEP izolasyon header'ları gerektirir. Duyuruya göre WebDB, özel header gerektirmeden herhangi bir statik host'tan veya CDN'den çalışıyor.

Depolama, dayanıklılık ve birden fazla sekme

Kaputun altında asenkron bir sanal dosya sistemi, OPFS ve IndexedDB üzerindeki 4 KB'lık page fault'larda askıya alınıyor. Yazıda daha alışılmadık bir yetenek daha vurgulanıyor: çok gigabyte'lük salt-okunur veritabanları, dosyanın tamamını indirmeden HTTP Range istekleriyle doğrudan S3'ten veya bir CDN'den sorgulanabiliyor.

Dayanıklılık, her 4 KB'lık sayfada CRC32 checksum'ları içeren write-ahead logging ile sağlanıyor; amaç, bir kullanıcı sekmeyi aniden kapattığında bozulmayı önlemek. Aynı veritabanını okuyup yazan birden fazla sekme navigator.locks üzerinden koordinasyon kuruyor ve motor, UUIDv7 ve ULID tanımlayıcılarını 36 karakterlik string'ler yerine 16 ham byte'a paketliyor; yazara göre bu, B+Tree insert'lerini daha hızlı ve fragmansız hale getiriyor.

Akıcı sorgular ve canlı UI güncellemeleri

Public API tipli bir query builder: tablolar tipli kolonlar ve composite index'lerle tanımlanıyor, sorgular join'ler, gruplama, HAVING clause'ları ve aggregate'lerle zincirleniyor ve üretilen bytecode planını incelemek için bir .explain() çağrısı mevcut.

UI işleri için kütüphane React, Vue, Angular ve düz JavaScript için binding'lerle geliyor; her biri gzip sonrası 1 KB'ın altında. Bir useLiveQuery hook'u, sorgunun yapısını — join'lenmiş tablolar dahil — inceliyor ve ilgili veri değiştiğinde sorguyu otomatik olarak yeniden çalıştırıyor; yazma işlemi ister mevcut sekmede ister bir Worker'da ister BroadcastChannel üzerinden başka bir tarayıcı sekmesinde gerçekleşsin.

Sayılar yazardan geliyor

Tüm performans rakamları kendi tarafından bildirilen değerler: 5.000 satırlık in-memory iş yükleri bir MacBook Pro M1 Max üzerinde çalıştırılmış. WebDB'nin WASM build'i bir range filter scan'de saniyede 1.091,7 işlem kaydederken resmi SQLite WASM 125,9 kaydetmiş (8,7 kat hız artışı); bulk insert'lerde saniyede 359.152 işlem'e karşılık 156.576 (2,3 kat) ve point lookup ile join'lerde daha küçük kazanımlar var. Bir sonuç tersine dönüyor: filter-sort-limit iş yükünde SQLite WASM (saniyede 1.483,7 işlem) WebDB'nin saf JS fallback'ini (saniyede 681,7 işlem) geçmiş, ancak WASM build'i yine de saniyede 2.381,0 işlemle en hızlı olmuş. Moussawi okuyucuları benchmark paketini kendilerinin çalıştırmaya davet ediyor. Paket @ahmadmoussawi/webdb adıyla mevcut; yanında ham sayfaları ve B+Tree yapılarını incelemek ile sıkıştırılmış veritabanı dosyalarını paylaşmak için tarayıcı tabanlı bir Studio playground'u bulunuyor.

Neden önemli

Local-first ve offline-first uygulamalar sürekli aynı duvara çarpıyor: tarayıcının depolama hikâyesi key-value caching için işe yarıyor ama ilişkisel iş yükleri için yaramıyor ve yaygın çözüm — bir masaüstü veritabanını çok megabyte'lık WASM olarak ship'lemek — bundle boyutu, sunucu header'ları ve CPU açısından maliyet taşıyor. WebDB'nin iddiaları yazarın kendi benchmark'larının ötesinde tutarsa, join'ler, index'ler ve transaction'lar içeren 20 KB altındaki bir motor bu engeli ciddi ölçüde düşürüyor ve header gerektirmeyen deployment gerçek bir operasyonel baş ağrısını ortadan kaldırıyor. HTTP range'ler üzerinden büyük salt-okunur veri kümelerini sorgulamak, masaüstü portlarının doğal olarak sunmadığı bir yetenek. Açık sorular ise olgunluk ve güven: bu, kendi makinelerinde kendi bildirdiği rakamlara sahip tek yazarlı bir proje ve SQLite'ın onlarca yıllık sağlamlaştırılması ile geniş araç ekosistemiyle yarışıyor.