[naked-ferret]

From the jepsen report:

"""

Curiously, MongoDB omitted any mention of these findings in their MongoDB and Jepsen page. Instead, that page discusses only passing results, makes no mention of read or write concern, buries the actual report in a footnote, and goes on to claim:

> MongoDB offers among the strongest data consistency, correctness, and safety guarantees of any database available today.

We encourage MongoDB to report Jepsen findings in context: while MongoDB did appear to offer per-document linearizability and causal consistency with the strongest settings, it also failed to offer those properties in most configurations.

"""

This is a really professional to tell someone to stop their nonsense.

[mathattack]

Amazing that anyone can trust Mongo after this BS.

[Thaxll]

MySQL and PG are not truly consistent per default, they don't fsync every writes.

MongoDB explains that pretty well: https://www.mongodb.com/faq and https://docs.mongodb.com/manual/core/causal-consistency-read...

[castorp]

> MySQL and PG are not truly consistent per default, they don't fsync every writes.

Postgres most certainly does fsync by default.

It's tru, you can disable it, but there is a big warning about "may corrupt your database" in the config file.

[Thaxll]

No PG does not fsync every writes, more details here: https://dba.stackexchange.com/questions/254069/how-often-doe...

My point is people complain about MongoDB are the one not using it most likely, MongoDB is very different from 10 years ago.

I like to remind people that PG did not have an official replication system 10years ago and as of today is still behind MySQL. No DB is perfect, it's about tradeof.

[wolf550e]

> It writes out and syncs the accumulated WAL records at each transaction commit, unless the committed transaction touched only UNLOGGED or TEMP tables, or synchronous_commit is turned off.

So wal is synced before commit returns, and if you power cycle immediately after, the wal is played back and your transaction is not lost? So it's fine?

It does not need to sync all writes, only the records needed to play back the transaction after restart. This is what all real databases do.

[robocat]

“PG writes out and syncs the accumulated WAL (= Transaction log) records at each transaction commit [snip] It also syncs at the end of each WAL file (16MB by default). The wal_writer process also wakes up occasionally and writes out and syncs the WAL.“

So PG keeps data consistent by default - unlike MongoDB.

> MySQL and PG are not truly consistent per default, they don't fsync every writes. MongoDB explains that pretty well [links]

Where in those MongoDB doc links is there anything about MySQL or PG?

[Carpetsmoker]

I don't know if this is true or not, but it's besides the point; MongoDB omitted various failings from the Jepsen report to make their product look better than it actually is. This is not only unethical, but may also be illegal in various jurisdictions under false advertising laws.

Whatever failings MySQL or PostgreSQL may or may not have are not important at all here.

[wolf550e]

The default in MySQL and in postgresql is to fsync before commit and afaik that has always been the default.

[Thaxll]

Not it was not the case and there was several serious issues with fsync and PG in the past: https://www.percona.com/blog/2019/02/22/postgresql-fsync-fai...

On MySQL: https://dev.mysql.com/doc/refman/8.0/en/innodb-dedicated-ser...

InnoDB uses O_DIRECT during flushing I/O, but skips the fsync() system call after each write operation.

The fsync thing is more complex than it looks like.

[dijit]

That bug was unfortunate, but you can't say that "it doesn't fsync" because, pedantically, it does, it just ignores the return value.

And, obviously that's a bug, it's designed to do so.

Also, if you write with O_DIRECT, a fsync is not needed, as it's how you tell the OS to block until written.

[foobarian]

From top of linked article:

>>> I have to admit raising an eyebrow when I saw that web page. In that report, MongoDB lost data and violated causal by default. Somehow that became "among the strongest data consistency, correctness, and safety guarantees of any database available today"! <<<

It's not wrong, just misleading. Seems overblown given that most practitioners know how to read this kind of marketing speak.

[takeda]

> It's not wrong, just misleading. Seems overblown given that most practitioners know how to read this kind of marketing speak.

So basically whatever MongoDB was doing 10 years ago, they are continuing to do there. They did not change at all, yesterday or two days ago there were few people defending mongo that indeed in early years mongo want the greatest, but it is now and people should just stop being hang up in the past.

The reason why people lost their trust with mongo wasn't technical, it was this.

[lostcolony]

I appreciate your optimism in thinking that most (all?) people reaching for distributed systems actually know enough in the space to evaluate such claims.

[takeda]

Agree, and the "Mongo and Jepsen" page isn't targeting distributed systems experts, most of them know to stay away, because even if there are things that mongo does right, other systems do it better.

[Carpetsmoker]

What other systems would you recommend?

[takeda]

I don't consider myself an expert in that area. Just someone who learned a lot from Kyle's articles.

Based on this, my understanding is: most of the time you want a relational database. If a relational database becomes a bottleneck for certain data, and you don't want to do typical scaling solutions for relational data, then you need to know what you'll trade for the higher performance. Based on what you trade, you then decide what kind of data store you will use.

[wolco]

What do you want to do?

[kvz]

FoundationDB

[kreetx]

Isn't that too low-level?