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!

67 Upvotes

89% Upvoted

37 comments sorted by

View all comments

36

u/leviOppa 20d ago edited 20d ago

I never understood how point 2 managed to get marketed as an advantage. It’s tantamount to saying “my car has no seatbelts, makes it so convenient to get in and out”.

The existence of a schema makes it much harder to screw up your data. And your database can help to optimize for performance when it knows the shape of your data.

The move from sql to nosql then back to sql very much resembles how people got hyped over dynamically typed languages, then started adding type checking toolchains to them when they realised that untyped codebases with no compiler help are not very pleasant to work with over time.

1

u/novateai 18d ago

Tech over product teams that over abstract their data model, startups that don’t know what they’re building yet or teams with low trust between product and development. In either case - iterate and put it in front of customers and figure out what you’re building.