SQLite Is All You Need (Until It Isn't)

Every side project I've ever abandoned died the same death: not from lack of ideas, but from infrastructure fatigue. Docker compose files. Connection pools. Migration tools that needed their own migration tools.

Then I started shipping everything on SQLite, and things started finishing.

The case for a file on disk

A database that is just a file has properties that are easy to underestimate:

• Backups are cp. Your entire disaster recovery plan fits in a cron job.
• Dev equals prod. No "works with my local Postgres 15 but prod is 13" surprises.
• Zero network hops. Reads are measured in microseconds, not milliseconds.
• Transactions are real. Full ACID, WAL mode, the works.

What the skeptics get wrong

The classic objection is concurrency. Here's the thing — with WAL mode enabled, readers never block writers and writers never block readers:

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

A single writer at a time sounds scary until you measure it. SQLite can sustain tens of thousands of writes per second on commodity hardware. Your blog is not going to hit that. Your startup probably won't either.

A quick comparison

Concern	SQLite	Managed Postgres
Setup time	0 seconds	an afternoon
Monthly cost	$0	$15–$500
Backup story	copy a file	tooling + prayer
p50 read latency	~10µs	~1ms + network
Horizontal scale	no	yes

That last row is the honest one. When you genuinely need multiple writer nodes, you've outgrown it — and congratulations, because that's a success problem.

Where I draw the line

Use boring technology until the pain is specific, measurable, and yours — not borrowed from someone else's postmortem.

If you have one box serving requests, use SQLite. When you have five boxes and a load balancer, we can talk. Until then, enjoy the quiet.