Genuine question: I appreciate the comments about MongoDB being much better than it was 10 years ago; but Postgres is also much better today than then as well. What situations is Mongo better than Postgres? Why choose Mongo in 2025?
In MongoDB the situation is different. You have to deal with the bare minimum of a database. But in return your data design has much higher horizontal scalability survivability.
In the initial phase of your startup, choose MongoDB. It's easier to start and evolve in earlier stages. And later on, if you feel the need and have resources to scale PostgreSQL, move your data there.
b) MongoDB does one thing well. JSON documents. If your domain model is built around that then nothing is faster. Seriously nothing. You can do tuple updates on complex structures at speeds that cripple PostgreSQL in seconds.
c) Nobody who is architecting systems ever thinks this way. It is never MongoDB or PostgreSQL. They specialise in different things and have different strengths. It is far more common to see both deployed.
Statements like yours are meaningless when you aren't specific about the operations, schema, access patterns etc.
If you have a single server, relational use case then PostgreSQL is great. But like all technology it's not great at everything.
In all seriousness, calling Postgres’ scalability “not-negotiable for most use cases” is wild.
"built-in, supported, proven scalability and high availability"
PostgreSQL does not have any of this. It's only good for a single server instance which isn't really enough in a cloud world where instances are largely ephemeral.
Excuse me? I do enterprise apps, along with most of the developers I know. We run like 100 transactions per second and can easily survive hours of planned downtime.
It's 2025, computers are really fast. I barely need a database, but ACID makes transaction processing so much easier.
granted, the failures were pretty minor, especially compared to previous reports (like the first one [1], that was a fun read), but they still had bad defaults back then (and maybe still do)
I would not trust anything MongoDB says without independent confirmation
Although I would point out:
> scalability [...] no company would even bother with PostgreSQL at all
In my experience, you can get pretty far with Postgresql on a beefy server, and when combined with monitoring, pg_stat_statements and application level caching (e.g. the user for this given request, instead of fetching that data on every layer of the request handling), certainly enough most businesses/organisations out there.
I've been playing with CloudNativePG recently and adding replicas is easy as can be, they automatically sync up and join the cluster without you thinking about it.
Way nicer than the bare-vm ansible setup I used at my last company.
On average an AWS availability zone tends to suffer at least one failure a year. Some are disclosed. Many are not. And so that database you are running on a single instance will die.
Question is do you want to do something about it or just suffer the outage.
That being said there are plenty of ways to shard Postgres that are free, e.g. Citus. It's also questionable whether many need sharding. You can go a long way with simply a replica.
Postgres also has plenty of its own strengths. For one, you can get a managed solution without being locked into MongoDB the company.
And history has not been nice to startups like this continuing their products over the long term.
It's why unless it is built-in and supported it's not feasible for most to depend on it.
Microsoft does not make money supporting Citus.
MongDB is basically a pile of JSON in comparison, no matter how much you distribute and scale it.
See https://jepsen.io/analyses for how MongoDB has a tradition of incorrect claims and losing your data.
Distributed databases are not easy. Just saying "it is web scale" doesn't make it so.
1. That PgSQL also has issues in jepsen tests?
2. of any distributed DB which doesn't have jepsen issues?
3. It is configurable behavior for MongoDB: can it lose data and work fast, or work slower and do not lose data. There is no issues of unintentional data loss in most recent(5yo) jepsen report for MongoDB.
Your second point seems to imply that everything has issues, so using MongoDB is fine. But there are various kinds of problems. Take a look at the report for RethinkDB, for example, and compare the issues found there to the MongoDB problems.
RethinkDB doesn't support cross document transactions, problem solved lol
MongoDB defects were, let's say, somewhat more severe
[2.4.3] "In this post, we’ll see MongoDB drop a phenomenal amount of data."
[2.6.7] "Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred. [...] almost all write concern levels allow data loss.
[3.6.4] "with MongoDB’s default consistency levels, CC sessions fail to provide the claimed invariants"
[4.2.6] "even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations"
let's not pretend that Mongo is a reliable database please. Fast? likely. But if you value your data, don't use it.
* why you are referring on 12yo reports for very early MongoDB version?
If you wish to have a more recent MongoDB report, Jepsen is available for hire, from what I understand.
Postgres is hard, you have to learn SQL. SQL is hard and mean.
Mongo means we can just dump everyone into a magic box and worry about it later.No tables to create.
But their is little time, we need to ship our CRUD APP NOW! No one on the team knows SQL!
I'm actually using Postgres via Supabase for my current project, but I would probably never use straight up Postgres.
It has supported this since 9.4: https://www.postgresql.org/docs/current/datatype-json.html
It's easier to get started with.
But why is that the top priority?
Maintainability? Secondary. Security? Secondary. Data-integrity/correctness? Secondary.
Writing code and creating good software requires a lot of mental clarity and effort; that fact is never going to change, not even with AI.
Firebase by and almost every NoSql technology is based upon this.