17 ms·
> Interesting idea - but like some other posts here I'm wondering how exactly writes and concurrency would work For writes, SQLite's single threaded restrictio
by sekao 5y ago
> Interesting idea - but like some other posts here I'm wondering how exactly writes and concurrency would work
For writes, SQLite's single threaded restriction still applies. But for most use cases, scaling reads is by far the most important thing.
> Why not just use a traditional DB like MySQL or Postgres on the backend and a WASM SQL client on the frontend?
The point is that you don't need a backend at all for reads, only for writes. All reads can be served by a static file host or cloud object store.
- xg15 5y agoMakes sense. I think especially for DBs that are mostly read-only, this seems like a really useful solution. In some way, this reminds me of the way some of the old image boards were written: Instead of querying the DB and rendering HTML on each GET, the HTML was regenerated on POSTs and written to disk as static files. All GETs were handled like static assets. This gave you high read performance, caching and partial reads for free, even for pages that normally would be dynamic. (Of course the cost was bad write performance and severe restrictions on dynamic or user-dependent content)
- beagle3 5y agoAnd with litestrean/rqlite/dqlite you could have multiple read replicas as well.