9 ms·

As someone that mostly shared that opinion for the last decade or more, I recently set up a cluster for work, and everything seems much more production level qu

As someone that mostly shared that opinion for the last decade or more, I recently set up a cluster for work, and everything seems much more production level quality than I remember or what I assumed it was going to be like. I'm not the one using it for queries every day, but I did do a bunch of testing for replication and failed nodes to confirm that I understood (and could rely) on the claims of robustness, and it seemed to be stable and with good documentation of what to expect in different scenarios and how to configure it (which is not what I experienced doing the same testing back in 2010-2011). All in all, my impression of MongoDB now is that they're one of those "fake it till you make it" success stories, where they leveraged their popularity into enough momentum to fix most their major problems.

outworlder 5y ago
One thing that turned me away from MongoDB was their utter lack of care for your data integrity that they displayed for years. Some of those instances were even documented. Then there were some bad defaults - some could _also_ cause data loss. For any component that's viewed as a database (as opposed to, say, cache), data integrity is one of the most important metrics (if not THE most). In contrast, PostgreSQL data loss bugs are rare - and are treated extremely seriously. Defaults are sane and won't lose data. It's one of the few databases I'm pretty confident that data will be there even if you yank a server power cord mid writes. Has MongoDB improved? Yes, leaps and bounds(seems to still fail Jepsen tests though). But I can't help but feel that it should have been released as a beta product, instead of claiming it was production ready. It wasn't. Maybe it is now. I'd still evaluate other alternatives before considering it. That said, one thing that always amuses me is how MongoDB gets mentioned in the same context as PostgreSQL. If PostgreSQL would meet your needs, it's unlikely that MongoDB would. And vice-versa(but maybe something else like Cassandra would).
- threeseed 5y ago
  Those defaults were changed a decade ago and were never an issue if you used a driver eg. Python. And the Jepsen tests are part of the core test suite so do you some evidence they are still failing. It’s so ridiculous and pointless to be rehashing the same issues a decade later. Actually more a testament to the company that it’s still hugely successful and depended on by some very large applications.
  - dralley 5y ago
    Perhaps, but mongodb was responsible for something I have bookmarked as "the worst line of code ever". Which decided whether or not to log connection warnings based on Math.random() https://github.com/mongodb/mongo-java-driver/blob/1d2e6faa80aeb5287a26d0348f18f4b51d566759/src/main/com/mongodb/ConnectionStatus.java#L212-L215 https://github.com/mongodb/mongo-java-driver/blob/1d2e6faa80...
    - threeseed 5y ago
      a) This is a line of code from 2013 and was fixed weeks after. b) Based on the JIRA [1] it was designed to only log 10% of subsequent failures where there is no connection to prevent log flooding. You would still get the initial failure message. Pretty reasonable technique and hardly the worst code ever. [1] https://jira.mongodb.org/browse/JAVA-836 https://jira.mongodb.org/browse/JAVA-836
  - __turbobrew__ 5y ago
    https://github.com/mongodb/mongo-java-driver/commit/d51b3648a8e1bf1a7b7886b7ceb343064c9e2225#diff-a4601c990f57148121efae9587a61e61afb4b7eb3f1f5537ad5aded607c5a0c3R212 https://github.com/mongodb/mongo-java-driver/commit/d51b3648...
- btown 5y ago
  Postgres with tables that are just an ID and a JSONB column nowadays give you practically everything you'd want out of MongoDB. You can add deep and customized indices as desired, you can easily shard with Citus, and if you want to live without transactions you'll see equally good if not better performance - with the option to add ACID whenever you want. The developer experience argument, where the ->> operator was more confusing than brackets, is now moot. As a former MongoDB user, there were good synergies between MongoDB and Meteor back in the day, and I loved that tech, but between Materialize and Supabase, you have vastly more options for realtime systems in the Postgres ecosystem.
- TedShiller 5y ago
  Although MongoDB claims in an undated article entitled "MongoDB and Jepsen"[65] that their database passed Distributed Systems Safety Research company Jepsen's tests, which it called “the industry’s toughest data safety, correctness, and consistency Tests”, Jepsen published an article in May 2020 stating that MongoDB 3.6.4 had in fact failed their tests, and that the newer MongoDB 4.2.6 has more problems including “retrocausal transactions” where a transaction reverses order so that a read can see the result of a future write.[66][67] Jepsen noted in their report that MongoDB omitted any mention of these findings on MongoDB's "MongoDB and Jepsen" page. from https://en.wikipedia.org/wiki/MongoDB#Bug_reports_and_criticisms https://en.wikipedia.org/wiki/MongoDB#Bug_reports_and_critic...
hodgesrm 5y ago
> All in all, my impression of MongoDB now is that they're one of those "fake it till you make it" success stories, where they leveraged their popularity into enough momentum to fix most their major problems. That's not all bad. The same could be said of MySQL. Both DBMS prioritized ease of use over data integrity in the early going.
- zozbot234 5y ago
  And yet PostgreSQL making the exact opposite choice has really paid off in the longer run. People used to dismiss it as simply a toy for academics to play with, and look where the project is today. It can easily surpass most NoSQL databases on their home turf.
  - hodgesrm 5y ago
    To be fair PostgreSQL 15 years ago also had a lot of problems storing data reliability. Some of them manifested as performance issues. I also heard a fair number of war stories about corruption with "large" databases (e.g., 1TB+). PG replication lagged MySQL for many years as well. These seem to be non-issues today. At this point there's effectively no difference in the durability of data stored in MySQL or PostgreSQL, so it's hard to argue that one or the other made a better choice. They just got there by different paths. In fact, PostgreSQL is winning back share in part because of licensing. GPLv2 is limiting for a lot of applications, and there continue to be concerns about Oracle ownership. It's also absorbed a lot of features from other databases like JSON support. That's not special to PostgreSQL though. It's been a trend since the beginning for SQL RDBMS and explains why they have stayed on top of the OLTP market for decades.
dralley 5y ago
>All in all, my impression of MongoDB now is that they're one of those "fake it till you make it" success stories, where they leveraged their popularity into enough momentum to fix most their major problems. The downside being that their reputation is now somewhat charred.
AtlasBarfed 5y ago
Jepsen test suite completely tore them a new one. I don't trust any allegedly distributed database that gets excoriated that badly by Aphyr. https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 That's just a bit more than a year ago. Come on. MongoDB is like Mysqldb. I am so so so tired of hearing "that's been fixed, it's great now", doing a paper-thin dive into things, and seeing there are massive problems still. I used MongoDB with Spring Data, it is impressively seamless. It's just that there are way too many people who have sold snake oil for a decade-plus now, and I don't trust what they say anymore, and won't for a long long time.
- kbenson 5y ago
  Let's be clear, I definitely don't think it's great. It's just that my immediate response prior to six months ago was to laugh at the mere suggestion it be put into production. The only reason it actually was put into production is because we had a vendor requirement on it (and why they thought it was sufficient, I'm not sure). There's a difference between "not suitable for anything because it's so buggy and there's been so many problems over the years" and "not suitable as a replacement for a real RDBMS for important data". For the former, I think my opinion was possible a little harsh for the current state of it. For the latter, yeah, I'm not going to blindly trust it for billing data and processing yet, that's for sure.
  - AtlasBarfed 5y ago
    So did you do app-level code to verify writes? Double checking, etc?
    - kbenson 5y ago
      I wrote a few small test programs to run doing continuous inserts to the master, and tested shutting down, firewalling off, and killing the process of different members of the cluster and how it recovered and if data loss was experienced by comparing data sets. It was sufficient for me to not feel like we were taking on undue risk by using it, and since our use case is not one where we're in major trouble if a problem does come about (restoring from daily backups should be sufficient) and we're not doing anything transactional, that's good enough. As I mentioned earlier, it was a vendor requirement, so we just wanted to make sure it wasn't something that was problematic enough to make us question the vendor's decision making.

outworlder 5y ago

One thing that turned me away from MongoDB was their utter lack of care for your data integrity that they displayed for years. Some of those instances were even documented. Then there were some bad defaults - some could _also_ cause data loss. For any component that's viewed as a database (as opposed to, say, cache), data integrity is one of the most important metrics (if not THE most). In contrast, PostgreSQL data loss bugs are rare - and are treated extremely seriously. Defaults are sane and won't lose data. It's one of the few databases I'm pretty confident that data will be there even if you yank a server power cord mid writes. Has MongoDB improved? Yes, leaps and bounds(seems to still fail Jepsen tests though). But I can't help but feel that it should have been released as a beta product, instead of claiming it was production ready. It wasn't. Maybe it is now. I'd still evaluate other alternatives before considering it. That said, one thing that always amuses me is how MongoDB gets mentioned in the same context as PostgreSQL. If PostgreSQL would meet your needs, it's unlikely that MongoDB would. And vice-versa(but maybe something else like Cassandra would).

threeseed 5y ago
Those defaults were changed a decade ago and were never an issue if you used a driver eg. Python. And the Jepsen tests are part of the core test suite so do you some evidence they are still failing. It’s so ridiculous and pointless to be rehashing the same issues a decade later. Actually more a testament to the company that it’s still hugely successful and depended on by some very large applications.
- dralley 5y ago
  Perhaps, but mongodb was responsible for something I have bookmarked as "the worst line of code ever". Which decided whether or not to log connection warnings based on Math.random() https://github.com/mongodb/mongo-java-driver/blob/1d2e6faa80aeb5287a26d0348f18f4b51d566759/src/main/com/mongodb/ConnectionStatus.java#L212-L215 https://github.com/mongodb/mongo-java-driver/blob/1d2e6faa80...
  - threeseed 5y ago
    a) This is a line of code from 2013 and was fixed weeks after. b) Based on the JIRA [1] it was designed to only log 10% of subsequent failures where there is no connection to prevent log flooding. You would still get the initial failure message. Pretty reasonable technique and hardly the worst code ever. [1] https://jira.mongodb.org/browse/JAVA-836 https://jira.mongodb.org/browse/JAVA-836
- __turbobrew__ 5y ago
  https://github.com/mongodb/mongo-java-driver/commit/d51b3648a8e1bf1a7b7886b7ceb343064c9e2225#diff-a4601c990f57148121efae9587a61e61afb4b7eb3f1f5537ad5aded607c5a0c3R212 https://github.com/mongodb/mongo-java-driver/commit/d51b3648...
btown 5y ago
Postgres with tables that are just an ID and a JSONB column nowadays give you practically everything you'd want out of MongoDB. You can add deep and customized indices as desired, you can easily shard with Citus, and if you want to live without transactions you'll see equally good if not better performance - with the option to add ACID whenever you want. The developer experience argument, where the ->> operator was more confusing than brackets, is now moot. As a former MongoDB user, there were good synergies between MongoDB and Meteor back in the day, and I loved that tech, but between Materialize and Supabase, you have vastly more options for realtime systems in the Postgres ecosystem.
TedShiller 5y ago
Although MongoDB claims in an undated article entitled "MongoDB and Jepsen"[65] that their database passed Distributed Systems Safety Research company Jepsen's tests, which it called “the industry’s toughest data safety, correctness, and consistency Tests”, Jepsen published an article in May 2020 stating that MongoDB 3.6.4 had in fact failed their tests, and that the newer MongoDB 4.2.6 has more problems including “retrocausal transactions” where a transaction reverses order so that a read can see the result of a future write.[66][67] Jepsen noted in their report that MongoDB omitted any mention of these findings on MongoDB's "MongoDB and Jepsen" page. from https://en.wikipedia.org/wiki/MongoDB#Bug_reports_and_criticisms https://en.wikipedia.org/wiki/MongoDB#Bug_reports_and_critic...

hodgesrm 5y ago

> All in all, my impression of MongoDB now is that they're one of those "fake it till you make it" success stories, where they leveraged their popularity into enough momentum to fix most their major problems. That's not all bad. The same could be said of MySQL. Both DBMS prioritized ease of use over data integrity in the early going.

zozbot234 5y ago
And yet PostgreSQL making the exact opposite choice has really paid off in the longer run. People used to dismiss it as simply a toy for academics to play with, and look where the project is today. It can easily surpass most NoSQL databases on their home turf.
- hodgesrm 5y ago
  To be fair PostgreSQL 15 years ago also had a lot of problems storing data reliability. Some of them manifested as performance issues. I also heard a fair number of war stories about corruption with "large" databases (e.g., 1TB+). PG replication lagged MySQL for many years as well. These seem to be non-issues today. At this point there's effectively no difference in the durability of data stored in MySQL or PostgreSQL, so it's hard to argue that one or the other made a better choice. They just got there by different paths. In fact, PostgreSQL is winning back share in part because of licensing. GPLv2 is limiting for a lot of applications, and there continue to be concerns about Oracle ownership. It's also absorbed a lot of features from other databases like JSON support. That's not special to PostgreSQL though. It's been a trend since the beginning for SQL RDBMS and explains why they have stayed on top of the OLTP market for decades.

dralley 5y ago

>All in all, my impression of MongoDB now is that they're one of those "fake it till you make it" success stories, where they leveraged their popularity into enough momentum to fix most their major problems. The downside being that their reputation is now somewhat charred.

AtlasBarfed 5y ago

Jepsen test suite completely tore them a new one. I don't trust any allegedly distributed database that gets excoriated that badly by Aphyr. https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 That's just a bit more than a year ago. Come on. MongoDB is like Mysqldb. I am so so so tired of hearing "that's been fixed, it's great now", doing a paper-thin dive into things, and seeing there are massive problems still. I used MongoDB with Spring Data, it is impressively seamless. It's just that there are way too many people who have sold snake oil for a decade-plus now, and I don't trust what they say anymore, and won't for a long long time.

kbenson 5y ago
Let's be clear, I definitely don't think it's great. It's just that my immediate response prior to six months ago was to laugh at the mere suggestion it be put into production. The only reason it actually was put into production is because we had a vendor requirement on it (and why they thought it was sufficient, I'm not sure). There's a difference between "not suitable for anything because it's so buggy and there's been so many problems over the years" and "not suitable as a replacement for a real RDBMS for important data". For the former, I think my opinion was possible a little harsh for the current state of it. For the latter, yeah, I'm not going to blindly trust it for billing data and processing yet, that's for sure.
- AtlasBarfed 5y ago
  So did you do app-level code to verify writes? Double checking, etc?
  - kbenson 5y ago
    I wrote a few small test programs to run doing continuous inserts to the master, and tested shutting down, firewalling off, and killing the process of different members of the cluster and how it recovered and if data loss was experienced by comparing data sets. It was sufficient for me to not feel like we were taking on undue risk by using it, and since our use case is not one where we're in major trouble if a problem does come about (restoring from daily backups should be sufficient) and we're not doing anything transactional, that's good enough. As I mentioned earlier, it was a vendor requirement, so we just wanted to make sure it wasn't something that was problematic enough to make us question the vendor's decision making.