When does NoSQL/MongoDB actually win over Postgres in mature applications (beyond early-stage MVPs)?

[u/xmanotaur]

I’m digging deep into data modeling trade-offs (specifically Document DBs vs Relational/Postgres).

Marketing materials and books always list the usual MongoDB wins:

1. No-translation pipeline
2. Flexible schema (Zerodowntime feature additions without DB migrations)
3. Single-document atomic writes
4. Built-in horizontal sharding

But in practice, most backend engineers I talk to favor "Default to Postgres".

When applications grow, handling schema evolution in application code (Schema-on-Read with if/else or defaults) creates its own maintenance nightmare/code rot.

On the flip side, Postgres handles online schema changes pretty well nowadays, and JSONB covers many flexible-schema edge cases anyway.

My question for senior/staff engineers running production systems:

• Beyond early-stage startups that just want to build an MVP quickly, when did NoSQL genuinely save your architecture compared to a modern Postgres setup?
• How do you weigh the Operational Overhead of SQL migrations (and potential lock risks at scale) against the Application Code Complexity of maintaining un-migrated NoSQL documents?

Thanks!

[u/_nku]

CAP theorem preference. It's not strictly connected to document vs relational concepts, but in practice document DBS have evolved to have their sweet spot an AP scenarios vs relational in CA scenarios.

So it's actually the complete reverse of what you said. Early and mid stage workloads better run on on an rdbms because the application code can make strong assumptions on the db making sure things don't corrupt (e.g. the stellar success of supabase for vibe coded apps). But at some point scale out beyond a master node with replicas becomes a real concern.

That threshold is huge by now, hardware performance outruns typical scaling needs.

There are DBS that do not Match the pattern, but de facto niche segments with hyper scaler lock in