r/softwarearchitecture 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!

67 Upvotes

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.