What does HackerNews think of wa-sqlite?
WebAssembly SQLite with experimental support for browser storage extensions
We currently use IndexedDB for the virtual filesystem underneath the wa-sqlite [1] WASM SQLite driver in the browser. But yup, that means a ~1.1MB WASM download.
We'll definitely stay with SQLite in the client. One of our key principles is full SQL support (any Postgres supported SQL on the server, any SQLite supported SQL on the client). So we won't go pure IndexedDB without a database on top.
There's a lot of cool stuff going on with OPFS and WASM SQLite atm, so the technical options are evolving fast.
In my opinion, what we need is:
1) A client-side performant SQLite database that supports live queries. I.e. you can automatically re-render the page when the queries change. That way your database can drive the UI and be the source of truth in regards to what's displayed on the screen.
2) A separate realtime syncing protocol that syncs database state to client state.
And ideally this is all open source, and that these two endeavors are not coupled tightly.
[1] Wa-sqlite is the best (imo) client-side db - better than than the official Sqlite WASM build (for now) because it had a indexeddb fallback for browsers that aren't the cutting edge Chrome.
[2] cr-sqlite is an interesting project using CRDTs to sync state around. However I still believe that for many production use-cases you want a ultimate server source of truth.
[3] Replicache is still the best closed source solution I know of.
[1] - https://github.com/rhashimoto/wa-sqlite [2] - https://github.com/vlcn-io/cr-sqlite [3] - https://replicache.dev/
[0] https://github.com/vlcn-io/cr-sqlite/
[1] https://github.com/rhashimoto/wa-sqlite/
[2] https://github.com/rhashimoto/wa-sqlite/discussions/63
[3] https://github.com/vlcn-io/cr-sqlite/#how-does-it-work