Every year someone asks why we haven’t moved off Postgres. Every year the answer is roughly the same — and the list of things Postgres can quietly absorb keeps growing.
The thing about Postgres is that it’s almost always the second-best tool for any specific job. There’s a faster KV store. A more elegant graph database. A vector database with better recall. And yet — for the median project, with the median team, on the median timeline — Postgres ends up being the right call about nine times in ten.
The boring case
You can hire for it. You can deploy it on anything. The docs are excellent. It hasn’t broken in production for any of our clients in the past four years. It absorbs new responsibilities — JSON columns, full-text search, vector embeddings, time-series with TimescaleDB — without forcing a migration.
“Boring is a feature. Boring is what lets the design and the writing carry the work.”
When we reach for something else
Three cases, mostly. (1) When the access pattern is genuinely a graph and the queries are getting weird in SQL. (2) When the working set is enormous and read latency under 10ms matters. (3) When the team genuinely knows the alternative better than they know Postgres.
Outside those, the answer to “should we use Postgres?” is “yes” and the more interesting question is what you’ll do with the time you saved.