choose Postgres, then keep going
Start here. When a project needs to store data, the default answer is Postgres. Not a decision to agonize over. Not a survey of engines. Postgres. Michael Stonebraker, who built it, says it plainly: "if you want to get going, you have a database problem, the answer is choose Postgres".
This is boring advice on purpose. The interesting question is not which database. It is when you are allowed to add a second one. The answer: when you hit a wall you can name and measure. Until then, one datastore.
Stonebraker is also the person who said one size fits none. Both things are true. The trick is knowing which end of the curve you are on.
At the high end, specialized engines win by a lot. Each one is architected for a single workload shape, and on that shape it beats a general row store by roughly an order of magnitude.
Stonebraker's number for the gap: "you give up an order of magnitude when you're running a database system that isn't architected for your kind of stuff". That is the high-end truth. A column store on a warehouse, a stream engine on a feed, vector search on embeddings — each is roughly 10x faster on its own workload than a row store pretending to do that job.
Read the same sentence from the other direction. Stonebraker: "at the low end it's absolutely the right one-size-fits-all... at the high end that's just not true". The order-of-magnitude penalty only bites once your workload is extreme enough that the specialized engine has anything to specialize on.
For everything below that, Postgres is the right general answer, and the reasons are unglamorous: huge community, free, easy to hire for, and an implementation of every data type you could want. JSON, full text, geospatial, arrays, ranges — all in one engine, all maintained, all documented. You do not give up an order of magnitude on a workload that was never going to saturate a row store in the first place.
There are exactly two scaling walls that justify reaching for a second engine. Both are concrete. Both are measurable. Neither is a vibe.
Until you are doing roughly a million transactions a second, a single Postgres handles the write load. Stonebraker: "until you're trying to do a million transactions a second it works just fine". If your real number is ten thousand, or a hundred thousand, you are not at the wall. You have a tuning problem or an indexing problem, not an engine problem.
The second wall is a data warehouse at petabyte scale that needs a column store and multiple nodes. Core Postgres has neither. No column store. No multi-node. When your analytics genuinely outgrow a row store and a single machine, that is when a ClickHouse or a Vertica earns its keep — and the 10x is real enough to pay for the second system.
-- Wall check, not a feeling:
-- writes near the ceiling?
SELECT now(), tup_inserted + tup_updated + tup_deleted AS writes
FROM pg_stat_database WHERE datname = current_database();
-- warehouse scans dominating? measure before you migrate.
-- if neither is at the wall, the answer is still Postgres.Default to Postgres. Treat adding a second engine as a decision you must justify, not a reflex. The justification is one of the two walls, stated as a number you measured: write throughput approaching a million per second, or a petabyte warehouse that a single row store cannot scan. Below those, the honest answer is the boring one — it works just fine.