Hacker News Reader

Comment by threeseed | Hacker News Reader

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.

View on HN

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

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

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.

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

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

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.

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.

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

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.

The use a text file.

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

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.

Do you mean ephemeral clients or Postgres servers?

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

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.

Great response. All arguments are valid and fair.

Reply on news.ycombinator.com