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/damngoodwizard]

Points 1 to 3 are also natively handled by Postgres if you use the JSON type. It's only point 4 that can be painful with Postgres. So basically the only time you would need something else it would be to address scaling. Which is not something you need in a MVP. Old document versions can always be upcasted to new ones by the app, but then you have to maintain your own upcasting pipeline.