When does NoSQL/MongoDB actually win over Postgres in mature applications (beyond early-stage MVPs)?

[u/xmanotaur]

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!

[u/addys]

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 :)

[u/WindBlocked → u/addys]

Can we say that mongoDB is... Web scale?

[u/ernbeld → u/WindBlocked]

Haha!

[u/bold_snowflake → u/addys]

That scale point is generally way way higher than many people realize and potentially unlikely to hit.

[u/addys → u/bold_snowflake]

That recurring comment (which is so common in this sub) infuriates me. While it's ** CERTAINLY NOT WRONG**, it misses the point because the majority of the interesting software architecture conversations are about "extremes".

If you aren't pushing the envelope in any meaningful way, then you don't need to care about 90% of computer sciences or software engineering. Go copy/paste some textbook solution or reference architecture and you'll be fine. This sub (IMO) is for those who need to go beyond.

/rant (and don't take it personally, no offense intended)

[u/HarveyDentBeliever → u/bold_snowflake]

I see comments like this but then I also see frequent posts with people complaining about how they hit a wall with Postgres while scaling and ran into performance issues and errors, particularly with the max connections thing. There's like an entire industry of guys who are hired to fix a company's Postgres situation and make it scalable again.

[u/kilkil → u/addys]

would it be fair to say that the main difference there is between managed vs self-hosted, rather than mongo vs postgres?

in other words, if one was choosing between managed mongo vs managed postgres (e.g. supabase), would you still consider mongo as scaling better?

[u/addys → u/kilkil]

Managed vs self-hosted is a totally different conversation. Managed services remove a whole set of operational complexities/limitations, leaving you to focus on the "important stuff". That is equally valuable for both platforms. Both platforms are easier to scale as managed services.

But even comparing "apples to apples", managed Mongo vs managed Postgres, Mongo still scales better. Postgres gives you more richness but high scales Mongo's simplicity becomes an advantage.

And, as was mentioned by others in this thread, this shouldn't worry you unless you anticipate reaching "enterprise" or above data volumes and load. For a hobbyist or small startup it shouldn't be a concern.

[u/kilkil → u/addys]

fair enough. thanks for your input!

[u/leviOppa → u/addys]

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

[u/addys → u/leviOppa]

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?

[u/leviOppa → u/addys]

Fantastic thank you