Hacker News new | ask | show | jobs
by theamk 482 days ago
PgSQL 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.

1 comments

In attempt to understand your motives in this discussion, I would like to ask question:

* why you are referring on 12yo reports for very early MongoDB version?

This discussion refers to the entire history of MongoDB reports, which shows a lack of care about losing data.

If you wish to have a more recent MongoDB report, Jepsen is available for hire, from what I understand.

No, discussion started with question "Why choose Mongo in 2025?" So, old jepsen reports are irrelevant, and most recent one from 2020 is somehow relevant.