Since MongoDB acquired WiredTiger and their relational database storage engine, technologists have been speculating on when MongoDB would support multi-document transactions. With this week’s announcement, the expectation is that they’ll be ready this summer as part of MongoDB 4.0.
Grigori Melnik of MongoDB claims that "80%-90% of applications don’t need multi-document transactions at all" (although this claim could be questionable, as hierarchical databases tend to have a lot of denormalized data that needs to be updated in multiple locations simultaneously to ensure consistency). He goes on to say:
Also, some developers and DBAs have been conditioned by 40 years of relational data modeling to assume multi-table/document transactions are a requirement for any database, irrespective of the data model they are built upon. Others are concerned that while multi-document transactions aren’t needed by their apps today, they might be in the future, and they don’t want to outgrow their database.
Support for multi-document transactions, a cornerstone of ACID, began with MongoDB 3.0. In this version MongoDB gained multiversion concurrency control (MVCC), a technique for snapshot isolation often associated with the PostgreSQL and Oracle relational databases. Recent versions of SQL Server also use MVCC for their "memory-optimized" tables.
MongoDB 3.2 added "read concern" support. Previously clients were given data as it was known to whichever node they were communicating with. The read concern option allowed clients to require that the data be known to the majority of the nodes. Note that according to the documentation, "regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.".
MongoDB 3.6 then provided what they refer to as "causal consistency". In prior versions of MongoDB, there was no guarantee that operations occur in a particular order. You could, for example, delete a set of records and then perform a read that would return the very records you just deleted. With causal consistency, you can indicate that the read operation depends on the result of the write operation, thus ensuring that the deletion completed before the read was performed.
Finally, MongoDB 4.0 will offer the ability to perform a consistent read. Which is to say, it will return only the data as it was known at the moment in time that the read operation began. As we explained in the article, A Quick Primer on Isolation Levels and Dirty Reads, previous versions of MongoDB could return results that were not necessarily consistent with any point in time. It could even skip documents or return multiple versions of the same document in a single query.
Developers wishing to experiment with multi-document transactions are encouraged to enroll in the MongoDB 4.0 beta program.