Postgres is all you need. I know because we learned it the hard way.

We had a MongoDB problem dressed up as a scaling problem.

In 2021, I was a senior IC at a Series B fintech with 180 engineers. We'd inherited MongoDB from the scrappy 12-person days. Flexible schema, fast iteration, no migrations. Classic early-stage reasoning. By the time we hit $4M ARR and real compliance requirements, that flexibility had become a $340k liability in migration work, duplicated validation logic, and three on-call incidents caused by documents with unexpected shapes.

The engineer who originally chose MongoDB was long gone. Nobody remembered why certain fields were optional. Our application code had grown a skeleton of defensive checks just to survive reading its own database.

What Postgres actually gives you

Postgres 15 has JSONB columns if you genuinely need flexibility. It has full-text search. It has lateral joins that will make your data team cry happy tears. It has pg_trgm for fuzzy matching. It has logical replication, row-level security, and generated columns.

One of my engineers said it best during our postmortem:

"We picked MongoDB so we could move fast. Then we spent a year moving slow because of MongoDB."

When I hear "we need NoSQL" now

As a manager, I treat it like a yellow flag. Not a red one. Sometimes it's the right call. Time-series data, massive write-throughput IoT workloads, pure document storage with truly unknown shape. Those exist.

But most teams reach for NoSQL because it feels modern. Or because a tech blog from 2013 scared them about Postgres at scale. Notion runs on Postgres. Shopify runs on MySQL. Instagram ran on Postgres to 1 billion users.

Your startup is not the exception. Start with Postgres. Add complexity only when you can name the specific constraint it solves.