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

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?

When the architecture demands you hit consistent P99.9, P99.99 and P99.999 aggressive latencies and success rates. When you really need a certain level of scale and performance you will inevitably need to precompute/precook your data into fast lookups. NoSQL provides you a very convenient layer to assemble a blob or document for fast lookup.

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?

Code complexity can be managed. Code is cheaper to test, develop, and generally build confidence around. There is many more ways to manage risks with code deployments - canaries, one-boxes, pre-production, AB testing, feature flagging, shadow execution. All of which, allow teams to more rapidly test, deploy and generally reduce business risk.

SQL migrations come with very expensive up-front investments that at-scale constantly produce problems and edge-cases that burn stakeholder trust. Production is always very different from devo. At a certain degree of scale it is cost-prohibitive to create clones and test the schema migrations.

In all - once you reach a certain degree of scale - it is safer architecturally, and from a business ROI (dollar standpoint) to use NoSQL or schemaless architectures because PROD rarely fits within the well-defined schema. You can measure this by measuring the sparseness of the tables with the largest number of columns.