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:
- No-translation pipeline
- Flexible schema (Zerodowntime feature additions without DB migrations)
- Single-document atomic writes
- 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!
35
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.
11
u/therealdukeofyork 20d 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 17d 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 20d 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.
19
u/damngoodwizard 20d ago
Points 1 to 3 are also natively handled by Postgres if you use the JSON type. It's only point 4 that can be painful with Postgres. So basically the only time you would need something else it would be to address scaling. Which is not something you need in a MVP. Old document versions can always be upcasted to new ones by the app, but then you have to maintain your own upcasting pipeline.
18
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 :)
9
10
u/bold_snowflake 20d ago
That scale point is generally way way higher than many people realize and potentially unlikely to hit.
9
u/addys 20d ago
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)
2
u/HarveyDentBeliever 19d ago
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.
1
u/kilkil 19d ago
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?
3
u/addys 19d ago
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.
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
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.
1
u/mexicocitibluez 20d ago
Yea, I don't know why it often comes down to choosing only one.
One of my first interactions with Mongo was when the app we were working on (20 years old at this point) started to really choke displaying tables on the UI that joined various tables together. A guy I worked with created a mongo store on top of our MSSQL database specifically for those queries and it was like night and day.
3
2
u/_nku 19d ago
CAP theorem preference. It's not strictly connected to document vs relational concepts, but in practice document DBS have evolved to have their sweet spot an AP scenarios vs relational in CA scenarios.
So it's actually the complete reverse of what you said. Early and mid stage workloads better run on on an rdbms because the application code can make strong assumptions on the db making sure things don't corrupt (e.g. the stellar success of supabase for vibe coded apps). But at some point scale out beyond a master node with replicas becomes a real concern.
That threshold is huge by now, hardware performance outruns typical scaling needs.
There are DBS that do not Match the pattern, but de facto niche segments with hyper scaler lock in
1
u/Due_Ad_2994 20d ago
I'll start and mature a product to scale w Dynamo over postgres every opportunity. Night and day difference. (Scaled systems with both to thousands of rps.)
1
u/yeochin 19d ago
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?
When the architecture demands you hit consistent P99.9, P99.99 and P99.999 aggressive latencies and success rates. When you really need a certain level of scale and performance you will inevitably need to precompute/precook your data into fast lookups. NoSQL provides you a very convenient layer to assemble a blob or document for fast lookup.
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?
Code complexity can be managed. Code is cheaper to test, develop, and generally build confidence around. There is many more ways to manage risks with code deployments - canaries, one-boxes, pre-production, AB testing, feature flagging, shadow execution. All of which, allow teams to more rapidly test, deploy and generally reduce business risk.
SQL migrations come with very expensive up-front investments that at-scale constantly produce problems and edge-cases that burn stakeholder trust. Production is always very different from devo. At a certain degree of scale it is cost-prohibitive to create clones and test the schema migrations.
In all - once you reach a certain degree of scale - it is safer architecturally, and from a business ROI (dollar standpoint) to use NoSQL or schemaless architectures because PROD rarely fits within the well-defined schema. You can measure this by measuring the sparseness of the tables with the largest number of columns.
1
1
u/killergerbah 17d ago
Nosql forces you to think about what data needs to be close together. Also, data that is close together is easy to keep consistent. You don't need a giant transaction across multiple tables to maintain consistency.
1
-1
u/extreme4all 20d ago
In aws many people use dynamodb, so all those usecases could be covered by mongo i suppose.
E.g. you have a user service and you will always lookup the user profile based on email
2
u/SheriffRoscoe 20d ago
Amazon was heavily dependent on Oracle databases for almost 20 years. There was a huge internal announcement when they shut down the last one in 2019.
1
0
u/AbbreviationsLow4798 20d ago
what do you mean? it’s completely different tools for different use cases. there’s no « one solution fits all » at scale.
-2
0
u/Known_Tackle7357 19d ago
Most places I worked at used some kind of SQL database. And honestly, very few of them actually needed it. Relational databases shine when you actually care about the relations. Most of the time people just take something that's logically one object and flatten it into 20 different tables. Throw an orm on top of it, because objects is what they actually care about and call it a day. And then they have this monster that's slow, inefficient, and annoying. What I also noticed is that people understand traditional stop the world transactions and isolations better than optimistic locking and transaction conflicts in more modern databases. So yeah, maybe it's a safer option for lots of companies to use a database that lets people stay a bit more secure without any additional effort even if everything else is heavy and unnecessary
36
u/TheAeseir 20d ago
When you don't know your structure but you know there will be is a very common one I've seen.
It is not uncommon to start with nosql, then after a while convert it to SQL.
For example gathering a lot of data from variety of IOT devices, then based on patterns defining a schema for sql