What's this about?
The recurring argument that one PostgreSQL instance can serve as your database, queue, cache, search index, job runner and more — avoiding a stack of specialized services. It drew 195 comments, including a substantial counter-current from SQLite users making the same argument one size smaller.
What exactly is the case for "just use Postgres"?
Every additional service in a stack is another thing to deploy, monitor, back up, upgrade and reason about when it fails. Postgres has grown extensions covering many of those needs — full-text search, JSON documents, geospatial via PostGIS, queues, even vector search — usually not as good as the dedicated tool, but good enough at moderate scale. The argument is that operational simplicity beats per-component optimality until you're large enough that it doesn't, and most systems never get there. The SQLite version of the argument goes further: for the long tail of applications, one file plus replication to object storage removes even the database server.
What's the community saying?
- "The older I get, the more I agree with this." The thread's prevailing sentiment, and a fair summary of why this argument keeps returning.
- A factual correction about MySQL opened the discussion: the post's claim that MySQL was faster because it skipped SQL-standard features refers to MyISAM, which hasn't been relevant in over a decade — InnoDB made different, defensible choices.
- The SQLite contingent was large and unrepentant: NVMe plus Litestream plus S3-compatible storage covers "the entire long tail of apps that aren't the Ubers and AirBnBs of the world."
- People have taken this further than the post. Links appeared to `pg_gpt2`, `pg_shell` and `pg_os` — running a language model, a shell, and an operating-system layer inside Postgres.
- "No mention of PostGIS — shameful." The obligatory and entirely justified complaint.