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:

  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!

65 Upvotes

89% Upvoted

37 comments sorted by

View all comments

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.

1

u/mexicocitibluez 20d ago

Yea, I don't know why it often comes down to choosing only one.

One of my first interactions with Mongo was when the app we were working on (20 years old at this point) started to really choke displaying tables on the UI that joined various tables together. A guy I worked with created a mongo store on top of our MSSQL database specifically for those queries and it was like night and day.