MongoDB 3.x was broken too[0]. Their reputation for consistently shipping databases with fundamental design defects is well-deserved. Data loss was a hallmark of that product across multiple major versions. Maybe they've suddenly turned a new leaf in the last couple years but I wouldn't want to bet my business on it. Most of the companies I know that use it, use it for data that doesn't matter such that data loss isn't a big deal.
I wrote for the technical writing team at MongoDB when this "security issue" made the news. The precise problem was whether authentication was turned off/on by default for the default database, I believe, during installation. Product management initially chose this configuration to make it quicker for evaluators to get something up and running as quick as possible. The assumption was that no developer would actually use that in production. Further, the documentation clearly stated that this default configuration option was not secure.
Blaming that data loss on MongoDB rather than the noob dev who deployed that evaluation configuration is as erroneous as the logic used by the noob dev. We hear it from developers all the time, so let me repeat it: User error. It's a thing.
That evaluation isn't about security; it's about durability -- does the database actually save your data under all circumstances?
In this Jepsen analysis, we develop new tests which show the MongoDB v0 replication protocol is intrinsically unsafe, allowing the loss of majority-committed documents. In addition, we show that the new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4. While the v0 protocol remains broken, fixes for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite.
It does look like it was fixed though.
I remember some mealy mouthing but maybe I got them confused with others subject to Jepsen tests ...
The parent refers to an issue from 2016 when 30000 (!) dbs on the internet got deleted/ransomed. The fact they blame the customers for this and totally confuse this with data loss is kinda telling huh? Sounds like data integrity wasn’t a big thing internally at mongo after all
Agreed. Unfortunately, getting most developers to pay attention to their users has historically been quite difficult. Asking them to distinguish between differing levels of technical expertise with the product within the same audience and for a specific context - noob devs with no product experience in this case - requires empathy for the user that is missing in most developers.
[0] https://jepsen.io/analyses/mongodb-3-4-0-rc3