MongoDB vs PostgreSQL: The Arguments Everyone Gets Wrong
A practical look at the MongoDB vs PostgreSQL arguments people often get wrong, from JSONB and schema flexibility to durability and benchmarks.
Most of the Postgres vs Mongo arguments I see online are based on assumptions that are either super outdated or just kind of technically wrong. The same topics keep coming up over and over on reddit, youtube, or whatever, and I wanted to write some of them down.
"PostgreSQL JSONB is basically MongoDB"
JSONB lets Postgres store documents, but it doesn't turn Postgres into a document database. Mongo's storage engine, replication, sharding, aggregation framework, indexing, update semantics, and query engine were all designed around documents from day one. JSONB is bolted onto a relational engine.
It's still really useful. But "just use JSONB" is kind of like saying "just throw a truck bed on a sedan and now it's a pickup." Like, technically there's overlap, but they're still doing different things.
"MongoDB is schemaless"
Actually, that's one of the most common misconceptions.
Mongo lets you have flexible documents, but modern Mongo has schema validation, required fields, type enforcement, unique indexes, and most of the guardrails you'd want from a regular database.
Most Mongo deployments that actually work in production aren't truly schema-free. They just enforce schema differently (usually at the app layer or with validators).
"MongoDB loses data"
This one is basically a meme from like 2013.
Back then:
- Default durability settings were weaker
- A lot of deployments ran without replica sets
- Some people disabled journaling (which... yeah)
Modern Mongo defaults are way safer. You get journaling, replica sets, majority-acknowledged writes, multi-document transactions, point-in-time recovery, and distributed replication. The "MongoDB loses data" thing is mostly people repeating something they heard a decade ago.
"MongoDB is only for lazy devs"
There are a lot of really smart database engineers and architects working at companies that run Mongo at scale. The choice usually has to do with the workload, not with anyone being lazy. Some workloads just map to documents better than they map to normalized tables.
The misconception usually comes from MongoDB's flexibility, plus developers designing their databases recklessly without thinking about the future. In Postgres, it's much harder to do that because of all its guardrails. But that doesn't mean MongoDB is for lazy developers.
"Postgres is always better"
That's... debatable. Postgres is one of the best databases ever made, and it's usually a safe default. I'm not arguing against that. But like everything in software engineering, databases are tools, not teams to root for.
The question isn't "which one is better." It's "which one matches the workload better."
If your data is super relational, Postgres usually wins. If your data is document-shaped, Mongo usually wins. A lot of real systems end up using both.
Why JSONB vs BSON Benchmarks Are Kinda Misleading
You see a lot of benchmarks where someone compares Mongo documents against Postgres JSONB documents and concludes Mongo is faster. From this video: https://www.youtube.com/watch?v=ZZ2tx8iL3P4 (I am not the author of the video).
And for that test, the numbers are probably right. But the conclusion people pull from them often isn't.
There's two things going on with benchmarks like this.
1. The data models aren't really comparable.
JSONB isn't really Postgres's main data model. So when you benchmark Mongo documents against Postgres JSONB documents, what you're actually comparing is:
- A document database
- A relational database being used as a document database
A fairer Postgres benchmark would model the same data using normalized tables, foreign keys, real indexes, joins, the whole thing. A lot of workloads that suck in JSONB are actually really fast once you model them properly. The reverse is true too. Workloads that feel natural in Mongo get weird when you force them into rows and joins.
2. The durability defaults aren't comparable either.
In that video specifically, Mongo was running with its default writeConcern, which only flushes the journal every 100ms. Postgres was running with its default WAL fsync on every commit. So Mongo gets to acknowledge writes faster, because it's literally promising less durability per write. That's not "Mongo is faster than SQL." That's "Mongo is faster when you let it relax its durability." Crank Mongo up to j: true or w: "majority" with proper sync and the gap closes a lot.
Durability Isn't a Mongo Weakness Anymore
Like I mentioned above, the "Mongo loses data" thing is mostly an artifact of how people ran Mongo in the early 2010s.
Modern Mongo gives you journaling, replica sets, majority-acknowledged writes, multi-doc transactions, point-in-time recovery, and distributed replication.
A write with:
writeConcern: { w: "majority" }
is durable across multiple replica set members before it even gets acknowledged.
The actual durability gap between a properly configured Mongo cluster and a properly configured Postgres cluster is way smaller than people assume. Most "is it durable" arguments these days are really arguments about operational choices and consistency models, not about the storage engine.
Where Mongo Actually Wins
There are real workloads where Mongo is just the better tool.
Documents that get mutated a lot
Mongo is great when you're updating documents constantly and each update only touches a small piece of the doc. Stuff like:
- Counters
- User state
- Device state
- Telemetry that gets enriched over time
- Session data
Postgres JSONB has to rewrite the whole JSONB value every time. Mongo often doesn't. This gap is huge in practice. Mongo can churn through partial updates at a rate that JSONB just can't match unless you pull the hot fields out into real columns.
Deeply nested data
Mongo handles nested objects, arrays, and embedded docs naturally. You don't have to join your way through five tables to assemble a real object.
Query patterns you can't predict yet
If your users can add arbitrary fields and then query them later, Mongo's flexibility is hard to beat. You don't have to know the schema ahead of time.
Horizontal write scaling
Mongo's sharding was built into the database from the start. Postgres can scale out too, but you usually end up with partitioning, extensions, distributed variants, or app-level sharding. None of those feel as native as Mongo's sharding does. That's one of MongoDB's biggest strengths.
Document-centric workloads
Mongo really shines when each request reads one doc, updates one doc, writes one doc. No joins, no fan-out, just the doc as the unit of work.
Big documents that change a lot
If your documents are large, mutated frequently, and accessed as a single unit, Mongo is basically designed for that.
Where Postgres Still Wins
Mongo's good at a lot, but Postgres still owns a few areas pretty cleanly.
Complex joins
Postgres's query planner is incredible. It's hard to overstate how good it is at joins. It actually outperforms MongoDB by a lot in a couple of public benchmarks.
Referential integrity
Foreign keys actually enforce relationships. Mongo can't really do this natively.
Reporting / analytics
SQL is still the language for analytics and BI. Pretty much every tool on the planet speaks it.
Heavily relational data
When your data is naturally graphy/relational, Postgres usually produces a cleaner design.
Multi-row transactions
Postgres's transaction model is one of its biggest strengths. Mongo has transactions too, but they're more limited.
A Java vs Python Way of Thinking About It
Here's an analogy that kind of clicks for me. You can almost think of SQL like Java and Mongo like Python.
Java has built-in types, strict structure, classes everywhere. It kind of forces you to organize your code and keep things modular. You can't really get away with being sloppy, because the language won't let you. SQL is similar. Schemas, types, constraints, foreign keys. The structure is enforced for you whether you want it or not.
Python is more like Mongo. Super flexible, super widely used, still really popular and not going anywhere. But if you don't have the self-discipline to make actual classes, structure your modules properly, and keep things organized, your codebase falls apart pretty fast. It's the same with Mongo. The flexibility is great until you stop enforcing schema at the app layer and your collections turn into a mess of inconsistent docs.
Neither is bad. Python is huge, Mongo is huge. They give you a lot of room to move fast. But the room to move fast is also the room to shoot yourself in the foot. Java and SQL take that choice away from you, which sucks when you want flexibility and is great when you need guardrails.
Different Tools, Different Assumptions
The way I think about it is that Postgres and Mongo aren't really competing for the same spot. They're built on different assumptions.
Postgres assumes:
- Relationships matter
- Consistency matters
- Joins matter
- Transactions matter
Mongo assumes:
- Documents are the unit of work
- Schema evolves
- Updates are localized
- Horizontal scaling matters
Neither one is universally right. The mistake is forcing your workload into the wrong set of assumptions, and then being mad when the database fights you. The best database is usually just the one whose assumptions most closely match what your app actually does.
A Quick Note on Where This Is Coming From
For context: I've been building a tool called VisuaLeaf for the last year and a half. It's a visual GUI for both MongoDB and PostgreSQL. Same workspace, same workflow, whichever database your data happens to live in. You can even migrate from sql databases to a mongodb database using VisuaLeafs Tasks/
Building it means I spend a kind of unreasonable amount of time inside both engines. A lot of these misconceptions come up in support tickets, reddit threads, and questions from people picking between the two, so I figured I'd dump them in one spot instead of typing the same reply over and over.
Working with MongoDB or PostgreSQL?
The best database choice depends on how your data is shaped and how your application uses it.
VisuaLeaf helps you explore MongoDB and PostgreSQL in one visual workspace, so you can browse data, understand structure, build queries, and work with your database more clearly.
Do you wanna try VisuaLeaf?