Correct me if I'm wrong, but MongoDB appears to have a 100-msec gap for its journaling behavior [0] by default. This would be akin to setting innodb_flush_log_at_trx_commit [1] = 2, which is not its default.

I also note that in their FAQs [2], they erroneously state:

"MongoDB’s data modeling best practice suggests storing related data together in a single document using a variety of data types, including arrays and embedded documents. So, a lot of the time, ACID is not required as it is a single-document transaction."

Whether or not you're operating on a single document has nothing to do with its ability to meet durability guarantees (or consistency, for that matter).

NoSQL databases make tradeoffs for performance, and making the lives of devs easier in the short term. That's fine, if and only if you accept what you're losing, and document it for others who may not be aware. If at any point you can have your application get a write ack'd and subsequently lose the write, you do not have a durable data store, and you do not have ACID compliance. Whether that's the fault of the DBMS, the operating system (Postgres' fsyncgate), or hardware (drives lying to the OS about the write's durability without the benefit of PLP) is irrelevant – you have to understand the entire chain to make those guarantees, or at the very least, trust your upstream provider to have understood it for you and made the correct decisions.

0: https://www.mongodb.com/docs/manual/core/journaling/

1: https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.ht...

2: https://www.mongodb.com/resources/products/capabilities/acid...