Every six months a new database eats the timeline. Most of them are interesting; almost none of them survive the third year. PostgreSQL has been our default for every project we've shipped since 2018, and we keep getting asked why. Short answer: it's still the highest-ROI dependency in the stack.
What makes it boring (and that's the point)
-
Transactions that actually work. Read-committed, repeatable-read, serializable — they behave the way the docs say they behave. Nobody else can quite say that.
-
A query planner that ages well. The optimiser has been getting steadily better for thirty years. Throwing a workload at it that worked five years ago still works today.
-
Recovery from anything. WAL archiving + base backups means a six-month-old database can be re-created bit-for-bit. We've actually had to do this twice. It worked both times.
-
Operators want to learn it. Recruiting against PostgreSQL is easy. Recruiting against the vector-database-of-the-month is a hiring tax.
The four extensions we always reach for
-
pgcrypto· UUIDs, hashes, symmetric encryption. Stop reaching for a separate service. -
pgvector· embeddings + cosine similarity. Closes the gap with the dedicated vector stores for everything below ~10M vectors. Pair with an HNSW index and you're done. -
pg_trgm· fuzzy text search without standing up Elasticsearch. Trigram indexes are surprisingly competitive for product-search workloads. -
btree_gin· multi-column GIN indexes for compound filters. Speeds up admin dashboards that filter onstatus + customer_id + created_atto the point of looking instant.
When we'd pick something else
-
Cassandra / DynamoDB when the write rate is genuinely above ~200k/s and the query shape is fixed.
-
ClickHouse for an analytics workload where the read pattern is huge aggregations over append-only data.
-
Redis for the cache. (We pick Redis with PostgreSQL, not Redis instead of it.)
Everything else, in 2026, is a CREATE DATABASE away.