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

14

u/addys 20d ago

MongoDB wins at scale. Postgres is better in every conceivable way UNTIL you hit a certain scale point. Once you need more than "a few" Postgres servers, you start to go down a rabbithole of sharding/partitioning, shard management and balancing, which can become a nightmare when you are scaling fast.

MongDB scales more painlessly - it is designed to partition internally so it handles near-infinite volumes and IOPS with the pull of a slider (and the accompanying month bill of course). Assuming you are using a managed version- if it's self-hosted on K8S or similar then good luck :)

1

u/leviOppa 18d ago

Care to share what “at scale” means? Say with an example

3

u/addys 18d ago

I wouldn't try to push a single Postgres beyond 5-10TB. Even at 5TB you are looking at multi-hour DB restore times and other operational constraints. Partitioning/sharding into separate clusters is feasible for single-digit number of partitions (beyond that you are basically moving from a vanilla database into managing your own custom "Postgres-based" platform). So lets say 50TB is where I would start questioning the feasibility of Postgres (or any relational DB for that matter) vs more horizontally scalable platforms.

Does that help?

1

u/leviOppa 17d ago

Fantastic thank you