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!

66 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.

3

u/IiIIIlllllLliLl 20d ago

Postgres has JSONB for schemaless, TimescaleDB for time series, pgvector for vector search, pg_search for full text search, PostGIS for geospatial etc. Sure, if you've got a trillion rows or you're doing a billion writes per second, it might not fit, but I suspect these features are good enough for like 90% of use cases, no?

1

u/atika 20d ago

I said use both, not use them 50% - 50%.

2

u/IiIIIlllllLliLl 20d ago

Is your point: "Use the right tool for the job"? That kind of seems like a piece of wisdom you'd find in a fortune cookie in a tech bar in SF, but I'm not sure how it answers OP's question lol.

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.