SQLite Is All You Need
dbpro.app
SQLite Is All You Need
1–10 of 66 posts
Re: SQLite Is All You Need
#2Author here. This started because I read Evan Hahn's STRICT tables post [1] last week and got curious how far "just use SQLite" actually holds up under real load, not toy benchmarks.
So I built a small social app (Chirp: 50k users, 1M posts, ~2.5M follows) in one SQLite file, put it behind a plain Node server, and load tested it properly: real HTTP, real JSON serialization, autocannon hammering it over sockets. The worst query in the app (home timeline, which joins follows against posts, counts likes, sorts by time) still did 3,654 req/s on an M1 laptop, which works out to 315M requests/day.
The part I didn't expect going in: WAL vs the old rollback journal isn't a minor tuning knob, it's the whole story. Same query, same data, one pragma changed, and p99 read latency goes from 4.4ms to 133ms once you add a writer. That's the "SQLite locks and blocks everyone" reputation, and it's from a database mode most people don't even use anymore.
I also tried to be honest about where it falls over: reads stop scaling once anything writes (page cache invalidation, not lock contention), there's one write lock for the whole DB, and there's no failover if the box dies. Those are real constraints, not disclaimers.
Also benchmarked Node+better-sqlite3 vs Bun+bun:sqlite since I had the harness built anyway. Bun wins on cheap queries, Node wins on the expensive ones. Wasn't expecting a split.
Happy to answer questions on methodology, the STRICT table stuff, or why we ended up building this the way we did.
Re: SQLite Is All You Need
#3The tests and the numbers are interesting. The LLM writing style? Insufferable.
It really wouldn’t have taken much effort to cut out the worst of the AI fluff, and maybe add some human touches
Re: SQLite Is All You Need
#4I could not agree more KISS is always the way to go.
For those people that are interested you can have a sqld instance on a different VM with S3 backup.
On my case I use k8s and the backend pod use rust libsqld crate with local first sql database file with remote sync to sqld.
When pod start if db file is not available libsqld will try recover it from slqd otherwise it will just load local db file and sync.
Re: SQLite Is All You Need
#5I could not agree more KISS is always the way to go. For those people that are interested you can have a sqld instance on a different VM with S3 backup. On my case I use k8s and the backend pod use rust libsqld crate with local first sql database file with remote sync to sqld. When pod start if db file is not available libsqld will try recover it from slqd otherwise it will just load local db file and sync.
[dead]
Re: SQLite Is All You Need
#6[flagged]
Re: SQLite Is All You Need
#7The tests and the numbers are interesting. The LLM writing style? Insufferable. It really wouldn’t have taken much effort to cut out the worst of the AI fluff, and maybe add some human touches
Sit with that for a second.*
* is in the article
Re: SQLite Is All You Need
#8lobster.rs also started using sqlite, i've been using exclusively using sqlite for most of my projects.
apps appear much faster because db is on the same server
Re: SQLite Is All You Need
#9And what do you do when you need more than one server, for redundancy or scaling to more servers?
Re: SQLite Is All You Need
#10> the Postgres container you spun up out of habit was never needed
These posts need to stop comparing their contrived use-cases for SQLite to Postgres. Sure, SQLite is all you need if it really is all you need. But Postgres does so much more than just act as a data dump with an SQL engine on top.
Dr. Hipp himself even said that SQLite does not, and will never, compete with the likes of Postgres. It competes with fopen.