The one-paragraph version
SQLite is the right default when your data fits on one machine and the writers are co-located with the data. That covers far more products than the 2010s 'use Postgres for everything' default suggested. The renaissance is real because the cost of putting compute near data — edge runtimes, single-server deploys, local-first apps — finally caught up with the technology that was always there.
Pick SQLite when:
- You have one writer (or can shard so each shard has one).
- Your reads are dominated by a single machine's reach.
- You value deployment simplicity (no daemon, no port, no auth tier).
- You can use Litestream / Turso / a per-tenant pattern to add replication where you need it.
- You want backup that's
cp.
Pick Postgres (or another server DB) when:
- Multiple writers across multiple machines must reach the same logical data.
- You need fine-grained per-user database authentication / row-level security.
- You need built-in synchronous replication and managed failover.
- Your team's expertise is concentrated there and the deployment story is solved.
Keep going from here: build something local-first. Index a real corpus with FTS5. Replicate a real database with Litestream. The renaissance is happening because people are doing those things, not because they're reading about them.