3 ms·

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 pro

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.

jeremycarter 2y ago
Great response. All arguments are valid and fair.
scosman 2y ago
A) Postgres easily scales to billions of rows without breaking a sweat. After that shard. It’s definitely negotiable.
- threeseed 2y ago
  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 2y ago
    The use a text file. In all seriousness, calling Postgres’ scalability “not-negotiable for most use cases” is wild.
    - threeseed 2y ago
      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 2y ago
        Do you mean ephemeral clients or Postgres servers?
  - g8oz 2y ago
    If multiple nodes are needed, then why MongoDB and not a Postgres compatible distributed product like CockroachDB or YugabyteDB?
delusional 2y ago
> 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 2y ago
  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
  - Tanjreeve 2y ago
    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 2y ago
    Last I checked they still didn't even implement pagination on their blog properly
  - theamk 2y ago
    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 https://jepsen.io/analyses/mongodb-4.2.6 [1] https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb
- touche_bag 2y ago
  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.
jamesrr39 2y ago
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 2y ago

Great response. All arguments are valid and fair.

scosman 2y ago

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

threeseed 2y ago
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 2y ago
  The use a text file. In all seriousness, calling Postgres’ scalability “not-negotiable for most use cases” is wild.
  - threeseed 2y ago
    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 2y ago
      Do you mean ephemeral clients or Postgres servers?
- g8oz 2y ago
  If multiple nodes are needed, then why MongoDB and not a Postgres compatible distributed product like CockroachDB or YugabyteDB?

delusional 2y ago

> 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 2y ago
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
- Tanjreeve 2y ago
  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 2y ago
  Last I checked they still didn't even implement pagination on their blog properly
- theamk 2y ago
  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 https://jepsen.io/analyses/mongodb-4.2.6 [1] https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb
touche_bag 2y ago
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.

jamesrr39 2y ago

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.