4 ms·
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.
by riku_iki 2y ago
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 2y agoAhhh, this sounds familiar! https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- riku_iki 2y agothings still can be true, even if being wrapped into meme videos by haters..
- itake 2y agoPostgres has replicas? Most people use those for reads and a master writes.
- Tostino 2y agoThis 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.
- threeseed 2y agoHigh 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 2y agoI think major providers provide PG service with cross zone availability through replication.
- amazingamazing 2y agoIt'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 2y agoCitus 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 2y agothat's fair, but that's true of mongodb itself too. I wouldn't count that against either of them.
- threeseed 2y agoMongoDB makes money selling and supporting MongoDB. Microsoft does not make money supporting Citus.
- codr7 2y agoCalling 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 2y agoI 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 2y agosigh See https://jepsen.io/analyses 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 2y agoAre 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 2y agoDistributed 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 2y ago> Take a look at the report for RethinkDB RethinkDB doesn't support cross document transactions, problem solved lol
- theamk 2y agoPgSQL 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.