better-sqlite3 VS sql.js

In the second video of the series, we are separating routers and adding SQLite, Better SQLite 3, Database to the application to show access to context for performing a simple query and mutation.

If I were charged with this task I'd probably take an actual SQLite DB and write methods to parse data from text files, then process it within SQLite, and serialize it back to the text file when an API method is called or after each processing step. A fresh DB engine, fully re-implemented to match SQLite's API is insane unless you're a prodigy or have a sizable team and will come with numerous downsides. I can recommend https://github.com/WiseLibs/better-sqlite3 and https://github.com/loveencounterflow/dbay

better-sqlite3 is orders of magnitude faster than the async SQLite bindings. We found this to be true when testing SQLite options for Notion's desktop app anyways.

https://github.com/WiseLibs/better-sqlite3#why-should-i-use-...

Better SQLite is a wrapper around the SQLite database engine that provides a number of improvements over the standard SQLite API. One of those benefits is type safety, Better SQLite uses TypeScript to provide type safety for queries, which can help to prevent errors.

better-sqlite3 does the job synchronously

I used better-sqlite3 . It is simple to use as it is synchronous. I don't know if it scales good (at least the docs say it) but works great for my small use cases.

Kent's recommended NodeJS module, `better-sqlite3`, has some very nifty features including the creation of JavaScript user-defined functions[0] that (if I understand this right) can be called from SQLite. Combined with TRIGGERs, I wonder if it might fire a function within the app when an UPDATE/INSERT happens from a different process? (This is me wondering out loud, I don't actually know.)

I also recommend checking out Replicache[1] and alternatives, which may be a better way to handle the networking and database replication so that it doesn't rely on the underlying DB.

[0] https://github.com/WiseLibs/better-sqlite3/blob/HEAD/docs/ap...

Hi HN! A friend and I were inspired by projects like https://github.com/sql-js/sql.js and the idea of querying files served over CDN with HTTP range requests. We started thinking: what would a database that was specifically designed for this type of use case look like? So we started building one, and we landed on a functional prototype that we're pretty proud of!

With our prototype, Appendable, we're able to serve and query large (GB+) datasets by hosting them on a static file host like Amazon S3 or Cloudflare R2 without running a separate server and worrying about things like tail latency, replication, and connection pooling -- all that is handled for us by the file hoster.

Additionally, one tenet that we have been following is Appendable won't touch your underlying data, so your jsonl file is preserved and we point at that data instead of consuming it into an Appendable-specific file format. This keeps your data yours and makes it easy to introspect the data: just open it up with your favorite editor aka vim.

We're curious what you think, we're excited to build this out further to get the performance even better and add features like pubsub. Everything is open source at https://github.com/kevmo314/appendable.

Kevin and Matthew

My project is powered by sql.js, I recommend checking that out if you're interested - https://github.com/sql-js/sql.js/

Maybe you can try to use some SQL database compiled as Web Assembly Modules? Like this one for example: https://github.com/sql-js/sql.js

If you want to have persistence, then I would go with a database like Dexie, as it uses IndexedDB and has transactions. If you just want something that's in memory, you could look at Sql.js or something simple like lowdb.

not necessarily. you can host an html/js/sqlite site on github pages for free. json -> sqlite3 js -> sql

Link: https://sql.js.org

Does it work with really large files? Like, >100mb or so. I was considering making something similar but with sqlite.js [1], but the problem with it is that it loads everything in memory, so I wasn't entirely sure how it will deal with larger workloads.

[1]: https://sql.js.org/#/