Every six months a new data layer arrives — an edge KV store, a multi-region SQL, a vector-only platform, a serverless Postgres-but-faster. Each one publishes benchmarks where it beats Postgres on a specific axis, and the conversation starts again about whether we should be building on it.
After running production Postgres for clients across six years and a handful of stack migrations, our default hasn't moved. Postgres still wins nine out of ten engagements. Here's why, and the rare cases where we actually pick something else.
What Postgres gives you for free
Postgres is five competent products in one process:
- 01A relational database with mature query planning, transactions, and constraints.
- 02Full-text search via tsvector that's good enough for most product surfaces — and avoids running a second cluster.
- 03JSONB columns with indexes, so schema-flex data lives next to relational data without a second store.
- 04Vector search via the pgvector extension — RAG retrieval against the same database the rest of the app already queries.
- 05Pub/sub via LISTEN/NOTIFY for in-process eventing — small enough to replace a queue for many workloads.
Each of those is a specialised product somebody else sells. Adopting them separately means five services to operate, five auth surfaces, five backup stories, five things that can drift out of sync. Postgres lets one team of two own the data layer end-to-end.
The benchmark question
Specialised stores almost always beat Postgres at the specific axis they specialise in. A vector-only database will out-perform pgvector on raw retrieval latency at scale. An edge KV store will beat Postgres on single-key reads from Sydney when Postgres is in Frankfurt.
The benchmark we actually care about is different. For a typical client workload — say, 10k queries/day mostly hitting cached pages, plus a thousand authenticated app requests — does the data layer support five concurrent reads and one write without thinking? Postgres does. Most clients never get within an order of magnitude of where the specialised store would matter.
When we actually leave Postgres
Three signals. If you see all three, leave. If you see one or two, don't yet:
- 01Specialised workload that dominates total query cost. Real-time analytics over billions of rows. Multi-region writes with strong consistency requirements. Vector search over millions of documents under tight latency budgets.
- 02Postgres' option is meaningfully slower than the alternative at your scale, measured — not assumed. Most teams skip the measurement and migrate anyway.
- 03The operational cost of running the specialised store separately is worth it — you have someone who can own it, monitor it, back it up, and rotate its credentials. If 'who pages on this' is unanswered, don't add it.
Where the modern Postgres options shine
The good news of the last few years: managed Postgres got dramatically better. Supabase makes auth + Postgres + storage a single service for product teams. Neon's branchable Postgres gives every PR a clone of production for QA. RDS and Cloud SQL are still the boring-and-reliable choices for serious workloads.
For most agency engagements we land on Supabase (when the product is auth-heavy and benefits from row-level security) or Neon (when the team wants per-branch databases for review apps). Both are still just Postgres underneath, which means everything we know about Postgres still applies. No new mental model required.
The contrarian view we hold
Most teams shouldn't be reading database benchmark blog posts. They should be reading Postgres' documentation. The hours invested in understanding EXPLAIN ANALYZE, index choices, partial indexes, and query planning return more than every alternative-data-layer migration we've seen, combined.
The boring choice isn't a compromise. It's the result of paying attention to which axis actually constrains your product. For most products, that axis is not database read latency from the nearest CDN edge. It's whether you can ship the feature this week and not page anyone at 3 AM about it. Postgres wins there.
If you're staring at a database migration RFP and trying to figure out whether the new shiny thing is worth it, the discovery call is the cheapest way to map it to your actual workload.