Postgres is enough

Half my consulting conversations lately start the same way: a small team, a straightforward product, and an architecture diagram with four databases on it. A document store for "flexibility," a search engine for one search box, a key-value store for sessions, and a relational database quietly doing all the actual work. My advice keeps getting shorter: use Postgres until Postgres tells you otherwise.

The features people buy other databases for

• Document flexibility? jsonb with indexing — schemaless where you need it, relational where you don't, in the same query.
• Search? Built-in full-text search covers the "one search box" case that teams deploy an entire Elasticsearch cluster to serve.
• Queues and pub/sub? LISTEN/NOTIFY and SKIP LOCKED run modest job workloads with zero new infrastructure.
• Scale? Partitioning and read replicas carry you much further than the conference-talk horror stories suggest — almost nobody outgrows a well-indexed Postgres before they outgrow their product.

Every database you add is a second thing that can be down, a second backup strategy, and a second thing your new hire has to learn. The feature had better be worth all three.

When I do reach for something else

Genuine cache pressure (Redis earns its keep), analytical workloads that want columnar storage, or write volumes with truly no relational shape. The point was never "Postgres is magic." It's that the boring default should have to lose an argument before you take on another moving part — and in most rooms I sit in, nobody's made the argument.