Hacker News Reader

Comment by gqewogpdqa | Hacker News Reader

MongoDB is used by enterprises all over the world. It's true that it's the easiest DB to get started with, and it's also true that in the distant past (pre 3.0, back in ~2015), they had some issues. But they now run the financial backends of companies as varied as banks and coinbase and... https://www.mongodb.com/who-uses-mongodb

View on HN

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.

[0] https://jepsen.io/analyses/mongodb-3-4-0-rc3

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

I think we're conflating two different issues.

Yes, this https://www.zdnet.com/article/hacker-ransoms-23k-mongodb-dat... has nothing to do with jepsen report pointing out durability issues within db engine itself which mongo was known for

Yeah, that was a separate issue, unrelated to the default authentication setting of the default db. And, yes, we fixed it.

> We hear it from developers all the time, so let me repeat it: User error. It's a thing.

And as developers, we should do our best to prevent the user from being able to make those errors.

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.

> The assumption was that no developer would actually use that in production. /.../ the noob dev

Ah, yes, classic "you're holding it wrong".

Reply on news.ycombinator.com