Sqlite3 WebAssembly

Original Article ↗ Hacker News Discussion ↗

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.