Hacker News new | past | comments | ask | show | jobs | submit
TiredGuy | on: Sqlite3 WebAssembly
So after downloading from the official downloads page and stripping away all the mjs files and "bundler-friendly" files, a minimal sqlite wasm dependency will be about 1.3MB.

For an in-browser app, that seems a bit much but of course wasm runs in other places these days where it might make more sense.

jsheard | parent | next
It's pretty compressible at least, sqlite3.js+wasm are 1.3MB raw but minifying the JS and then compressing both files with Brotli gets them down to 410KB.
loading story #41852828
coder543 | parent | next
1.3MB seems perfectly reasonable in a modern web app, especially since it will be cached after the first visit to the site.

If you’re just storing user preferences, obviously don’t download SQLite for your web app just to do that… but if you’re doing something that benefits from a full database, don’t fret so much about 1MB that you go try to reinvent the wheel for no reason.

If the other comment is correct, then it won’t even be 1.3MB on the network anyways.

loading story #41851925
flockonus | parent | next
It's a good consideration, together with the fact browsers already have IndexedDB embedded. One use case still for in-browser apps like Figma / Photoshop-like / ML apps, where the application code and data is very big anyway, 1.3Mb may not add that much

Also worth considering parsing of wasm is significantly faster than JS (unfortunately couldn't find the source for this claim, there is at lease one great article on the topic)

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...

aidos | root | parent
When we built our frontend sync system we tried a few different options. We had a fairly simple case of just trying to store entities so we could pull incremental updates since you were last online. The one we ran in production for a while was IndexedDB but found the overhead wasn’t worth it.

I played around with warm sqlite too. That was really nice but I decided against it due to the fact that it was totally unsupported.

ncruces | parent | next
For server side, you'll likely need a different build of Wasm SQLite, that handles concurrency (and file locking) differently.

Also, WASI is very far from answer (so far). The SQLite amalgamation builds fine for WASI but concurrency is an unsolved issue.

I had to build a VFS from scratch to get my Wasm based SQLite driver into a usable shape.

https://github.com/ncruces/go-sqlite3/blob/main/vfs/README.m...

jt2190 | parent | next
The thing to keep in mind is that the WebAssembly sandbox model means that in theory the program (SqlLite in this case) can run wherever it makes sense to run it. That might mean running it locally or it might mean running on a central server or it might mean running nearby on the “edge”.
loading story #41855860
loading story #41854092
loading story #41852258