MongoDB Documentation, Release 3.0.4 11.4.12 Does MongoDB support transactions? MongoDB does not support multi-document transactions. However, MongoDB does provide atomic operations on a single document. Often these document-level atomic oper- ations are sufficient to solve problems that would require ACID transactions in a relational database. For example, in MongoDB, you can embed related data in nested arrays or nested documents within a single document and update the entire document in a single atomic operation. Relational databases might represent the same kind of data with multiple tables and rows, which would require transaction support to update the data atomically. Atomicity and Transactions (page 80) MongoDB provides the following guarantees in the presence of concurrent read and write operations. These guarantees hold on systems configured with either the MMAPv1 or WiredTiger storage engines. Although MongoDB provides these strong guarantees for single-document operations, read and write operations may access an arbitrary number of documents during execution. Multi-document operations do not occur transactionally and are not isolated from concurrent writes. This means that the following behaviors are expected under the normal operation of the system, for both the MMAPv1 and WiredTiger storage engines: Atomicity and Transactions (page 80) Yes, readers can see the results of writes before they are made durable, regardless of write concern level or journaling configuration. As a result, applications may observe the following behaviors: 11.4.14 Can reads see changes that have not been committed to disk? See also: 11.4.13 What isolation guarantees does MongoDB provide? See also: Chapter 11. Frequently Asked Questions 762 1. Non-point-in-time read operations. Suppose a read operation begins at time t$_{1}$ and starts reading documents. A write operation then commits an update to a document at some later time t$_{2}$ . The reader may see the updated version of the document, and therefore does not see a point-in-time snapshot of the data. 2. Non-serializable operations. Suppose a read operation reads a document d$_{1}$ at time t$_{1}$ and a write operation updates d$_{1}$ at some later time t$_{3}$ . This introduces a read-write dependency such that, if the operations were to be serialized, the read operation must precede the write operation. But also suppose that the write operation updates document d$_{2}$ at time t$_{2}$ and the read operation subsequently reads d$_{2}$ at some later time t$_{4}$ . This introduces a write-read dependency which would instead require the read operation to come after the write operation in a serializable schedule. There is a dependency cycle which makes serializability impossible. 3. Dropped results. Reads may miss matching documents that are updated or deleted during the course of the read operation. However, data that has not been modified during the operation will always be visible. 3. Correctness with respect to sort. For read operations that request a sort order (e.g. db.collection.find() or db.collection.aggregate() ), the sort order will not be violated due to concurrent writes. 2. Correctness with respect to query predicates, e.g. db.collection.find() will only return documents that match and db.collection.update() will only write to matching documents. 1. Read and write operations are atomic with respect to a single document and will always leave the document in a consistent state. This means that readers will never see a partially updated document, and indices will always be consistent with the contents of the collection. Furthermore, a set of read and write operations to a single document are serializable.