To what extent are 'lost data' criticisms still valid of MongoDB?

Question

To what extent are \'lost data\' criticisms still valid of MongoDB? I\'m referring to the following:

1. MongoDB issues writes in unsafe ways b

Answer 1

I can't speak for every case, only my own. However unlike the other answer I don't work for Mongo or its competitors, I have lost data when using MongoDB, and used Mongo for around ten years, so here goes.

2010

This is when I first began using Mongo, the main criticisms of Mongo around the time were:

• Supposedly stable versions of Mongo had major data-losing bugs that weren't made explicit to users. Eg, prior to 1.8 non-clustered configurations were likely to lose data. This was documented by Mongo, but not to the extent a data losing bug in a stable-versioned DB would normally be.

The main defence of that criticism was:

• Users were informed of this danger, albeit not so explicitly. Users should read all the documentation before they begin.

In my own case, I was using 1.7 in a single server configuration but aware of the risk. I shut down the DB to take a back up. The act of shutting down the DB itself lost my data, 10gen assisted (for free) but were unable to recover the data.

2013

Later, in 2013, a study came out revealing MongoDB defaults can cause significant loss of acknowledged writes during network partitions.

Also in 2013 Mongo the official production node Mongo drivers wrapped and threw away all errors.

2014

Since then, in 2014 a completely different bug in the stable MongoDB driver bit me and many other users.

2016 (and again in 2020)

In 2016, the Meteor project has issues with MongoDB queries not always returning all matching documents.

Later MongoDB's policy of listening on all interfaces by default with no admin password set has also worked out badly for many users. We knew two decades ago (and probably earlier, but I wasn't in tech at the time) that listening on all ports by default was a bad idea, which is why other software avoids this.

2020 update: the Meow attack now automatically destroys databases with Mongo's old network defaults.

2020

Jepsen evaluated MongoDB 4.2.6 and concluded:

even at the strongest levels of read and write concern, MongoDB 4.2.6 failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes and allow dirty reads, even downgrading requested safety levels at the database and collection level.

Conclusion

There have been general, repeated observations, over many years, that Mongo has unsafe defaults to win performance benchmarks. Mongo generally responds that the user should be aware of these by reading all the relevant docs and may use choose to use safe options if they are needed.

As of 2020 I feel like MongoDB now is actually a more stable product simply through time and investment, however I will never trust the company for using our data to beta test for a decade, and I would not be surprised at all if another data loss condition was revealed. I have used Postgres JSONB, FoundationDB and RethinkDB as structured data stores which may be valid alternatives.