5 ms·

MongoDB: a) has a proven, supported, easy-to-use horizontal scaling solution. PostgreSQL doesn't. b) is ridiculously faster than PostgreSQL at per-tuple docum

MongoDB: a) has a proven, supported, easy-to-use horizontal scaling solution. PostgreSQL doesn't. b) is ridiculously faster than PostgreSQL at per-tuple document updates. c) has clients which are tailored for operations and data structures around documents. d) is easier to install, configure and manage.

coldtea 3y ago
I thought all those points died along with the hype ("MongoDB is web scale"), as all were wrong. Those were the marketing points people mentioned in their "honeymoon phase" posts. Then after using it in production, actual benchmarks and comparisons coming in, came the regret and moving on posts. In fact, most of those mentioned moving from Mongo to Postgres, and there was a full blow "yeah, NoSQL was a dumb idea for 99% of use cases, and Mongo even more so" discussion. In the end MongoDB was the butt of a joke, there were whole memes about it. So this comment is like a trip down memory lane, or into an alternate universe, where it's like 2012 and these things never happened.
- isoprophlex 3y ago
  You're wrong. MongoDB is web scale. /s
  - re-thc 3y ago
    But is it PlanetScale?
  - romanovcode 3y ago
    It's not 2012 anymore ;)
- seedless-sensat 3y ago
  How is (a) wrong? Pg doesn't horizontally scale like Mongo does
  - re-thc 3y ago
    > Pg doesn't horizontally scale like Mongo does At what cost though? Does 1 Pg server = 1 Mongo server for the same specs or do you need a lot more Mongo servers?
  - coldtea 3y ago
    Between plain old horizontal scaling via custom sharding, replicas, and extensions like Citus and Timescale that offer full horizontal scalability, Postgres is handling some of the biggest use cases in the world.
    - endisneigh 3y ago
      It's simply a fact that Postgres does not offer out of the box scaling like MongoDB. Postgres does have things like Citus, or even wire-protocol compatible things like CockroachDB that do scale, but those are not Postgres. It's the same situation with MySQL vs. Vitess.
      - riku_iki 3y ago
        > but those are not Postgres. sure, citus is an extension of postgres and part of ecosystem.
        hot_gril 3y ago
        And it comes with a bunch of caveats. It's bolted-on horizontal scaling, vs MongoDB where that's the main feature. Yes I still prefer Postgres in general, but it's fair to point out that weakness of it.
    - threeseed 3y ago
      Citus was acquired by Microsoft so there are doubts about its future longevity given that so many similar promises of ongoing support are rarely maintained. Timescale is optimised for time-series so not sure it's applicable. Point still remains that PostgreSQL lacks a modern, built-in horizontal scalability solution.
- threeseed 3y ago
  At least in my experience it is all still the case today. If you are dealing exclusively with documents I find MongoDB to be faster, better and easier to use. If my data model is hybrid or purely relational then I would use PostgreSQL. After all these years I am still waiting for an horizontal scalability solution for PostgreSQL that is up to the level of a modern database. It's 2023 and for many of us in enterprise environments it's a mandatory NFR. But it seems like you're not interested in a having an actual technical discussion.
  - coldtea 3y ago
    >But it seems like you're not interested in a having an actual technical discussion. You mean like the "technical" bullet points that could just as well be marketing copy?
  - prmoustache 3y ago
    did you try citus? https://www.citusdata.com/product/community https://www.citusdata.com/product/community
    - deleted 3y ago
      [deleted]
    - aeyes 3y ago
      It has serious limitations and needs a lot of elbow grease to run at scale. With some of the alternatives (for example MongoDB) you basically just add a few more machines and you are good. In my opinion Citus is still only a hack which is only useful if for some reason you can't move away from Postgres but you have reached the limit of what you can get out of a single machine.
  - nesarkvechnep 3y ago
    Well, your data model could become relational if you normalize it.
    - skywhopper 3y ago
- LtWorf 3y ago
  They used it at my first full time job out of university. It was terrible. It was not fast, a regular SQL db would have been much better, due to bugs in our code, the data in mongodb was not uniform, which led to failures in the code when the document didn't have the expected format. Cherry on top is that they were mostly growing documents, which is a very slow operation, that would have been done very fast with a many-to-many table in SQL instead.
  - fkyoureadthedoc 3y ago
    > due to bugs in our code, the data in mongodb was not uniform It supports schemas though right? https://www.mongodb.com/docs/manual/core/schema-validation/ https://www.mongodb.com/docs/manual/core/schema-validation/
    - deleted 3y ago
      [deleted]
    - VancouverMan 3y ago
      If I'm not mistaken, that was added relatively late, in version 3.2, which was released in December 2015.
- skywhopper 3y ago
  It all depends on your data structure and problem space. It was silly to dismiss RDBMSes as obsolete 10 years ago, and it's silly to dismiss document databases or other NoSQL databases today. There are plenty of use cases for which Mongo is far superior to Postgres. A wise engineer chooses the best tool for the job.
- jameshart 3y ago
  If you base your technology decisions on what the current memes are on /r/technology, you're going to have that impression, sure. But in reality, no, there wasn't a vote held in 2016 where we all agreed NoSQL was a mistake and we should go back to RDBMSs. The horizontal replication story in Mongo is just a different game. And because it's so reliable, that ends up being how you solve not just availability and scalability but also engine upgrades and config changes. I migrated a bunch of production transactional databases on Mongo Atlas from a GCP cluster to an AWS cluster, with zero read/write downtime, by just walking through simple cluster reconfiguration steps. Add some nodes in AWS... move the write master... remove some nodes from GCP. It was stress free and easy. The same trick with replication on Postgres was a nail biter every time we did it.
sambeau 3y ago
Thanks. Just what I was looking for.
riku_iki 3y ago
> MongoDB: does mongodb support ACID transactions? I think this is one of the key question in making decision.
- varelaz 3y ago
  All operations related to a single document are ACID. MongoDB supports multi-document transactions, but with higher performance cost. https://www.mongodb.com/docs/manual/core/transactions/ https://www.mongodb.com/docs/manual/core/transactions/
  - riku_iki 3y ago
    Your doc doesn't state ACID support, but only atomicity (first A in ACID).
    - Too 3y ago
      https://www.mongodb.com/basics/acid-transactions https://www.mongodb.com/basics/acid-transactions
      - riku_iki 3y ago
        also jepsen report says that it is mongo marketing assessment, and they are not really acid: MongoDB’s claim of “full ACID transactions” which “maintain the same data integrity guarantees you are used to in traditional databases” could be misleading. We recommend that users who are accustomed to serializable behavior evaluate critical transactions carefully, to identify whether running at snapshot isolation could violate application-level constraints. MongoDB may wish to revise their marketing language to use “snapshot isolated” instead of “ACID”. https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6
varelaz 3y ago
PostgreSQL will be horizontaly scaling if you can avoid joins and index range locks. But the thing is you don't want to, or why do you need SQL database then. I found MongoDB good for cases when you need a lot of upserts, your data model is looks like document and you don't need joins. Like you store events data for further processing or collect stats or counters with tags/indexes.
okr 3y ago
e) MongoDb is web-scale. ;-> (personally i like the schema-lessness)
- ralusek 3y ago
  Postgres json/jsonb

coldtea 3y ago

I thought all those points died along with the hype ("MongoDB is web scale"), as all were wrong. Those were the marketing points people mentioned in their "honeymoon phase" posts. Then after using it in production, actual benchmarks and comparisons coming in, came the regret and moving on posts. In fact, most of those mentioned moving from Mongo to Postgres, and there was a full blow "yeah, NoSQL was a dumb idea for 99% of use cases, and Mongo even more so" discussion. In the end MongoDB was the butt of a joke, there were whole memes about it. So this comment is like a trip down memory lane, or into an alternate universe, where it's like 2012 and these things never happened.

isoprophlex 3y ago
You're wrong. MongoDB is web scale. /s
- re-thc 3y ago
  But is it PlanetScale?
- romanovcode 3y ago
  It's not 2012 anymore ;)
seedless-sensat 3y ago
How is (a) wrong? Pg doesn't horizontally scale like Mongo does
- re-thc 3y ago
  > Pg doesn't horizontally scale like Mongo does At what cost though? Does 1 Pg server = 1 Mongo server for the same specs or do you need a lot more Mongo servers?
- coldtea 3y ago
  Between plain old horizontal scaling via custom sharding, replicas, and extensions like Citus and Timescale that offer full horizontal scalability, Postgres is handling some of the biggest use cases in the world.
  - endisneigh 3y ago
    It's simply a fact that Postgres does not offer out of the box scaling like MongoDB. Postgres does have things like Citus, or even wire-protocol compatible things like CockroachDB that do scale, but those are not Postgres. It's the same situation with MySQL vs. Vitess.
    - riku_iki 3y ago
      > but those are not Postgres. sure, citus is an extension of postgres and part of ecosystem.
      - hot_gril 3y ago
        And it comes with a bunch of caveats. It's bolted-on horizontal scaling, vs MongoDB where that's the main feature. Yes I still prefer Postgres in general, but it's fair to point out that weakness of it.
  - threeseed 3y ago
    Citus was acquired by Microsoft so there are doubts about its future longevity given that so many similar promises of ongoing support are rarely maintained. Timescale is optimised for time-series so not sure it's applicable. Point still remains that PostgreSQL lacks a modern, built-in horizontal scalability solution.
threeseed 3y ago
At least in my experience it is all still the case today. If you are dealing exclusively with documents I find MongoDB to be faster, better and easier to use. If my data model is hybrid or purely relational then I would use PostgreSQL. After all these years I am still waiting for an horizontal scalability solution for PostgreSQL that is up to the level of a modern database. It's 2023 and for many of us in enterprise environments it's a mandatory NFR. But it seems like you're not interested in a having an actual technical discussion.
- coldtea 3y ago
  >But it seems like you're not interested in a having an actual technical discussion. You mean like the "technical" bullet points that could just as well be marketing copy?
- prmoustache 3y ago
  did you try citus? https://www.citusdata.com/product/community https://www.citusdata.com/product/community
  - deleted 3y ago
    [deleted]
  - aeyes 3y ago
    It has serious limitations and needs a lot of elbow grease to run at scale. With some of the alternatives (for example MongoDB) you basically just add a few more machines and you are good. In my opinion Citus is still only a hack which is only useful if for some reason you can't move away from Postgres but you have reached the limit of what you can get out of a single machine.
- nesarkvechnep 3y ago
  Well, your data model could become relational if you normalize it.
  - skywhopper 3y ago
LtWorf 3y ago
They used it at my first full time job out of university. It was terrible. It was not fast, a regular SQL db would have been much better, due to bugs in our code, the data in mongodb was not uniform, which led to failures in the code when the document didn't have the expected format. Cherry on top is that they were mostly growing documents, which is a very slow operation, that would have been done very fast with a many-to-many table in SQL instead.
- fkyoureadthedoc 3y ago
  > due to bugs in our code, the data in mongodb was not uniform It supports schemas though right? https://www.mongodb.com/docs/manual/core/schema-validation/ https://www.mongodb.com/docs/manual/core/schema-validation/
  - deleted 3y ago
    [deleted]
  - VancouverMan 3y ago
    If I'm not mistaken, that was added relatively late, in version 3.2, which was released in December 2015.
skywhopper 3y ago
It all depends on your data structure and problem space. It was silly to dismiss RDBMSes as obsolete 10 years ago, and it's silly to dismiss document databases or other NoSQL databases today. There are plenty of use cases for which Mongo is far superior to Postgres. A wise engineer chooses the best tool for the job.
jameshart 3y ago
If you base your technology decisions on what the current memes are on /r/technology, you're going to have that impression, sure. But in reality, no, there wasn't a vote held in 2016 where we all agreed NoSQL was a mistake and we should go back to RDBMSs. The horizontal replication story in Mongo is just a different game. And because it's so reliable, that ends up being how you solve not just availability and scalability but also engine upgrades and config changes. I migrated a bunch of production transactional databases on Mongo Atlas from a GCP cluster to an AWS cluster, with zero read/write downtime, by just walking through simple cluster reconfiguration steps. Add some nodes in AWS... move the write master... remove some nodes from GCP. It was stress free and easy. The same trick with replication on Postgres was a nail biter every time we did it.

sambeau 3y ago

Thanks. Just what I was looking for.

riku_iki 3y ago

> MongoDB: does mongodb support ACID transactions? I think this is one of the key question in making decision.

varelaz 3y ago
All operations related to a single document are ACID. MongoDB supports multi-document transactions, but with higher performance cost. https://www.mongodb.com/docs/manual/core/transactions/ https://www.mongodb.com/docs/manual/core/transactions/
- riku_iki 3y ago
  Your doc doesn't state ACID support, but only atomicity (first A in ACID).
  - Too 3y ago
    https://www.mongodb.com/basics/acid-transactions https://www.mongodb.com/basics/acid-transactions
    - riku_iki 3y ago
      also jepsen report says that it is mongo marketing assessment, and they are not really acid: MongoDB’s claim of “full ACID transactions” which “maintain the same data integrity guarantees you are used to in traditional databases” could be misleading. We recommend that users who are accustomed to serializable behavior evaluate critical transactions carefully, to identify whether running at snapshot isolation could violate application-level constraints. MongoDB may wish to revise their marketing language to use “snapshot isolated” instead of “ACID”. https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6

varelaz 3y ago

PostgreSQL will be horizontaly scaling if you can avoid joins and index range locks. But the thing is you don't want to, or why do you need SQL database then. I found MongoDB good for cases when you need a lot of upserts, your data model is looks like document and you don't need joins. Like you store events data for further processing or collect stats or counters with tags/indexes.

okr 3y ago

e) MongoDb is web-scale. ;-> (personally i like the schema-lessness)

ralusek 3y ago
Postgres json/jsonb