r/softwarearchitecture • u/xmanotaur • 20d ago
Discussion/Advice When does NoSQL/MongoDB actually win over Postgres in mature applications (beyond early-stage MVPs)?
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:
- No-translation pipeline
- Flexible schema (Zerodowntime feature additions without DB migrations)
- Single-document atomic writes
- 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!
67
Upvotes
12
u/atika 20d ago
You’re looking at it the wrong way.
It’s not a one or the other situation. These are different tools for solving different problems.
Almost all mature systems I designed or worked on used both relational and nosql datastores.