[jamesrr39]

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?

[rudolph9]

Don’t choose Mongo. It does everything and nothing well. It’s a weird bastard of a database—easily adopted, yet hard to get rid of. One day, you look in the mirror and ask yourself: why am I forking over hundreds of thousands of dollars for tens of thousands' worth of compute and storage to a company with a great business operation but a terrible engineering operation, continually weighed down by the unachievable business requirement of being everything to everyone?

[g7r]

I have experience using both MongoDB and PostgreSQL. While pretty much spoken here is true, there is one more scalability aspect. When a fast moving team builds its service, it tends to not care about scalability. And in PostgreSQL there are much much more features that prevent future scalability. It's so easy to use them when your DB cluster is young and small. It's so easy to wire them up into the service's DNA.

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.

[beAbU]

Mongo is Web scale.

[leowoo91]

instagram use postgresql and still web-scale (unless this was satire)

[terafo]

https://www.youtube.com/watch?v=b2F-DItXtZs

[plasma_beam]

I have not watched that video since 2013 (wow!) and it is still hilarious.

[riku_iki]

they obviously didn't use vanilla postgres, but built some custom sharding on top, which is untrivial task (implementation and maintenance(resharding, failover, replication, etc)).

[koakuma-chan]

Choose Mongo if you need web scale.

[threeseed]

a) MongoDB has built-in, supported, proven scalability and high availability features. PostgreSQL does not. If it wasn't for cloud offerings like AWS Aurora providing them no company would even bother with PostgreSQL at all. It's 2025 these features are not-negotiable for most use cases.

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.

[delusional]

> It's 2025 these features are not-negotiable for most use cases.

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.

[redwood]

MongoDB has had ACID transactions for many years. I encourage folks to at least read up on the topic they are claiming to have expertise in

[theamk]

They failed every single Jepsen test, including the last one [0]

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

[0] https://jepsen.io/analyses/mongodb-4.2.6

[1] https://aphyr.com/posts/284-call-me-maybe-mongodb

[Tanjreeve]

Reputation matters. If someone comes to market with a shoddy product or missing features/slideware then it's a self created problem that people don't check the product release logs every week for the next few years waiting for them rectifying it. And even once there is an announcement people are perfectly entitled to have scepticism that it isn't a smoke and mirrors feature and not spend hours doing their own due diligence. Again self created problem.

[winrid]

Last I checked they still didn't even implement pagination on their blog properly

[touche_bag]

100? I had a customer with 10k upserts incl merge logic for the upserts while serving 100k concurrent reads. Good luck doing that with a SQL database trying to check constraints across 10 tables. This is what Nosql databases are optimized for... There's some stand-out examples of companies scaling even mysql to ridiculous sizes. But generally speaking, relational databases don't do a great job at synchronous/transactional replication and scalability. That's the trade off you make for having schema checks and whatnot in place.

[delusional]

I guess I didn't make myself clear. The number was supposed to be trivially low. The point was that "high performance" is like the least important factor when deciding on technology in my context.

[scosman]

A) Postgres easily scales to billions of rows without breaking a sweat. After that shard. It’s definitely negotiable.

[threeseed]

So does a text file.

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.

[scosman]

The use a text file.

In all seriousness, calling Postgres’ scalability “not-negotiable for most use cases” is wild.

[threeseed]

What's wild is you misrepresenting what I said which was:

"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.

[tristan957]

Do you mean ephemeral clients or Postgres servers?

[g8oz]

If multiple nodes are needed, then why MongoDB and not a Postgres compatible distributed product like CockroachDB or YugabyteDB?

[jamesrr39]

Thanks for these comments, I appreciate it.

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.

[jeremycarter]

Great response. All arguments are valid and fair.

[riku_iki]

Mongo is real distributed and scalable DB, while postgres is single server DB, so main consideration could be if you need to scale beyond single server.

[throw14082020]

Ahhh, this sounds familiar! https://www.youtube.com/watch?v=b2F-DItXtZs

[riku_iki]

things still can be true, even if being wrapped into meme videos by haters..

[itake]

Postgres has replicas? Most people use those for reads and a master writes.

[Tostino]

This can take you really damn far.

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.

[codr7]

Calling MongoDB a real database compared to PostgreSQL is hilarious.

MongDB is basically a pile of JSON in comparison, no matter how much you distribute and scale it.

[riku_iki]

I think there is no distributed db on the market available with features parity to PgSQL. Distributed systems are hard, and sacrifices need to be made.

[jwr]

sigh

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.

[riku_iki]

Are you aware:

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.

[jwr]

Distributed databases are not easy. You can't simplify everything down to "has issues". Yes, I did read most Jepsen reports in detail, and struggled to understand everything.

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.

[riku_iki]

> Take a look at the report for RethinkDB

RethinkDB doesn't support cross document transactions, problem solved lol

[theamk]

PgSQL only defect was anomaly in reads which caused transaction results to appear a tiny bit later, and they even mentioned that it is allowed by standards. No data loss of any kind.

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.

[riku_iki]

In attempt to understand your motives in this discussion, I would like to ask question:

* why you are referring on 12yo reports for very early MongoDB version?

[jwr]

This discussion refers to the entire history of MongoDB reports, which shows a lack of care about losing data.

If you wish to have a more recent MongoDB report, Jepsen is available for hire, from what I understand.

[threeseed]

High availability is more important than scalability for most.

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.

[riku_iki]

I think major providers provide PG service with cross zone availability through replication.

[amazingamazing]

It's sad that this was downvoted. It's literally true. MongoDB vs. vanilla Postgres is not in Postgres' favor with respect to horizontal scaling. It's the same situation with Postgres vs. MySQL.

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.

[threeseed]

Citus is owned by Microsoft.

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.

[amazingamazing]

that's fair, but that's true of mongodb itself too. I wouldn't count that against either of them.

[threeseed]

MongoDB makes money selling and supporting MongoDB.

Microsoft does not make money supporting Citus.

[999900000999]

Simple.

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.

[codr7]

If learning SQL is hard, maybe software isn't the best choice of career.

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.

[999900000999]

Billions upon billions of value have been created just upon the premise that SQL is hard.

Firebase by and almost every NoSql technology is based upon this.

[SEJeff]

Postgres supports JSONB natively. It literally speaks mongo line protocol and you can shove unstructured json into it.

It has supported this since 9.4: https://www.postgresql.org/docs/current/datatype-json.html

[999900000999]

I don't necessarily agree with the above justifications, but in my experience this is basically why teams pick Mongo.

It's easier to get started with.

[codr7]

Now there's a truth about MongoDB, it's easy to get started with.

But why is that the top priority?

[FridgeSeal]

Because some devs and teams prioritise “get to prod” above literally all else.

Maintainability? Secondary. Security? Secondary. Data-integrity/correctness? Secondary.

[SEJeff]

It’s hard to disagree with you on that part. PG is definitely not free to get starts with and requires a bit of setup (hello pg_hba.conf).

[winrid]

Yes but updating nested fields is last write wins, and with mongo you could update two fields separately and have the writes succeed, it's not equivalent.

[SEJeff]

Can you provide an example or documentation please?

[winrid]

When you write to a postgres jsonb field it updates the entire JSONB content, because that's how postgres's engine works. Mongo allows you to $set two fields on the same document at the same time, for example, and have both writes win, which is very useful and removes distributed locks etc. This is just like updating specific table columns on postgres, but postgres doesn't allow that within columns, you'd have to lock the row for updating to do this safely which is a PITA.

[chpatrick]

Even as a JSON document store I'd rather use postgres with a jsonb column.

[tiltowait]

Why is that? I found Postgres's JSONB a pill to work with beyond trivial SELECTs, and even those were less ergonomic than Mongo.

[chpatrick]

Because you get the convenience of having a document store with a schema defined outside of the DB if you want it, along with the strong guarantees and semantics of SQL.

[chpatrick]

For example: let's say you had a CRM. You want to use foreign keys, transactions, all the classic SQL stuff to manage who can edit a post, when it was made, and other important metadata. But the hierarchical stuff representing the actual post is stored in JSON and interpreted by the backend.

[cryptonector]

I thought this was sarcasm till the last sentence. Now I'm not sure.