SQLite in production isn't a meme anymore. But there are still cases where you absolutely need Postgres — and cases where you don't.
A year ago I would've laughed at someone suggesting SQLite for a production web app with serious traffic. Then I read the Turso benchmarks, the Litestream write-ups, and watched Fly.io build their entire platform on it. Now I'm not laughing.
SQLite isn't the toy database you used in a college course. The SQLite codebase has more test coverage than almost any software you've ever used. It's battle-tested in billions of devices. The WAL mode, combined with tools like Litestream for replication and Turso for edge distribution, makes it a legitimate option for a lot of apps that would've defaulted to Postgres five years ago.
The killer advantage is operational simplicity. No connection pooling. No separate database server. No network latency on queries. If your app and database live on the same machine, you're doing local file I/O, which is fast in ways that feel almost unfair compared to the network round-trip to a Postgres instance.
Concurrent writes at scale. SQLite's write lock is per-database. One writer at a time. For read-heavy apps this is fine — WAL mode lets readers and writers coexist. But if you're handling thousands of concurrent writes, Postgres's MVCC is genuinely better.
Also: complex queries, full-text search at scale, extensions like pgvector for embeddings, logical replication, row-level security. Postgres's extension ecosystem is 20 years deep. SQLite's is catching up but it's not there yet.
Pick SQLite when you want simplicity and reads dominate. Pick Postgres when writes scale or you need the ecosystem.
Most apps don't need to choose at the architecture level. They need to pick what fits their current scale and be honest about where they're going. I've seen teams run Postgres clusters for apps that get 50 requests per day. I've seen SQLite handle 10,000 requests per second on a $6 VPS.
Pick the tool that fits the problem. Don't cargo-cult either direction.