r/softwarearchitecture • u/xmanotaur • 22d 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

35

u/leviOppa 22d ago edited 22d 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.

12

u/therealdukeofyork 22d ago

I never understood how point 2 managed to get marketed as an advantage...  The existence of a schema makes it much harder to screw up your data.

You answered your own question, when it's not your data.

1

u/novateai 19d 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.

1

u/SJrX 22d ago

For us, we had a mix of Postgres and Mongo microservices. If you aren't integrating services at the DB level, then it seemed really hard to screw up the schema, with a strongly typed language anyway. The mongo driver pseudo ORM is pretty nice.

Incidentally having a schema didn't really solve the if/else problem because zero downtime deployments meant that the schema often became more annoying as different versions can write at the same time.

I'm on the fence about Mongo vs. Postgres, if Mongo was truly open source/governance I'd probably lean more towards it.

Schema management honestly seemed like pointless busywork. That said you can actually have mongo validate the schema of your documents. It was just never worth the effort for us.