Sqlite3 WebAssembly

Original Article ↗ Hacker News Discussion ↗

SQLite compiled to WebAssembly is enabling full SQLite databases to run directly in the browser, opening up new possibilities for offline-first and local-first web apps that need richer querying than IndexedDB. Commenters weigh the trade-offs of adding a ~400 KB–1.3 MB dependency to web bundles against the simplicity and power of SQL, debating when that cost is justified and how it compares to today’s already heavy front ends. They also explore persistence options like OPFS, sync patterns inspired by tools such as Litestream and CouchDB/PouchDB, and broader questions about WebAssembly on the server, standards like WebSQL and WASI, and how much official support projects should provide for ecosystems such as npm or Rust.

Bundle size, performance, and “weight”

  • Core WASM+JS payload is ~1.3 MB raw; reports of ~400 KB with minification + Brotli.
  • Some see this as trivial for serious web apps (Figma‑like, ML, dashboards) and acceptable given caching and lazy loading.
  • Others argue that “a megabyte here, a megabyte there” adds up, especially for first‑load on mobile where size + decompression + WASM scaffolding introduce visible delay.
  • Discussion veers into general frustration with multi‑MB JS and even large HTML; debate over whether this makes adding SQLite “reasonable” or just more bloat.

Persistence and browser storage

  • Official WASM build supports multiple persistence backends: OPFS VFS (with and without SharedArrayBuffer/COOP‑COEP), plus localStorage/sessionStorage for small DBs.
  • One OPFS VFS requires SharedArrayBuffer (thus COOP/COEP), another trades features to avoid that requirement.
  • For typical use, DB persistence “just works”; explicit importing/exporting is optional.
  • IndexedDB is criticized as awkward, under‑specified, and under‑maintained (limited indexing, weak query model, MDN docs quality).
  • Some worry that a good SQLite/WASM story will further reduce incentives to fix IndexedDB.

Use cases and local‑first patterns

  • Commonly cited scenarios: offline‑first apps, heavy client‑side tools (media, 3D, modeling), static sites with rich querying, dashboards that talk directly to third‑party APIs, and privacy‑preserving local‑only apps via File System Access.
  • Several sync engines and query libraries are mentioned; developer ergonomics and “local‑first” tooling are seen as promising but still immature.

WebSQL, standards, and “browser‑native” SQL

  • Reminder that earlier WebSQL was effectively SQLite in browsers but stalled because all vendors used the same engine and standards bodies wanted multiple independent implementations.
  • Some commenters feel killing WebSQL set the web back; others prefer today’s model where sites ship their own up‑to‑date SQLite/WASM instead of being stuck with browser‑frozen versions.
  • Proposals to standardize a SQLite API in browsers raise concerns about versioning, maintenance burden, binary size, and implied endorsement; many see WASM as the cleaner compromise.

WAL, replication, and sync complexity

  • Idea: run SQLite in‑memory in the browser and stream WAL to a server for rehydration and replication.
  • Multiple replies describe this as technically possible but non‑trivial: browser WASM lacks the shared‑memory primitives SQLite’s WAL and tools like Litestream expect; WAL in this environment often ends up “exclusive” and loses concurrency benefits.
  • Alternative approaches exist (custom VFS layers, triggers, session extension, statement‑level replication) but involve significant engineering and trade‑offs, especially around determinism and partial sync.

Ecosystem integrations and server‑side WASM

  • There is an “officially sanctioned” npm package, but the core project intentionally only ships vanilla JS/WASM and avoids committing to any specific JS toolchain.
  • Active work exists around Rust (ORM integration, custom VFS in Rust), Go (WASM driver with Go‑implemented VFS), and JVM (experimental pure‑JVM runtime via WASM).
  • Server‑side WASM runtimes (WASI, Wasmer, Wasmtime, etc.) are mentioned; opinion is mixed on whether WASM will become a mainstream server deployment target versus remaining niche for specific use cases.