Every few months a client arrives with an architecture diagram containing six data stores: Postgres, Redis, Elasticsearch, a vector database, a queue and a time-series store. Almost every time, we ship the project with one.
This is not contrarianism. It is arithmetic: every additional store is a second failure mode, a second backup strategy, a second thing the on-call engineer must understand at 3am.
What Postgres absorbed
JSONB killed our need for a document store in most products. Full-text search with tsvector covers the search box on ninety percent of applications. pgvector handles embeddings well past the scale most startups will ever reach. SKIP LOCKED gives you a perfectly good job queue, and a timestamp index gets remarkably far into time-series territory.
The pattern is consistent: the specialised store is better at its speciality, and irrelevant until you hit a scale most products never reach.
Where it genuinely is not enough
Faceted search over millions of documents with typo tolerance — use a search engine. Sub-millisecond cache reads at high concurrency — use Redis. Analytical scans over billions of rows — use a columnar warehouse. Multi-region active-active writes — that is a distributed systems project, not a database choice.
The discipline is to prove the need with production numbers before adding the second store. A benchmark on realistic data takes a day and settles the argument either way.