Snapshot isolation provides a consistent view of data as of the transaction start but can allow write skew anomalies, while serializable isolation prevents all anomalies by ensuring transaction execution is equivalent to some serial order
In MongoDB, multi-document transactions use snapshot isolation by default. This provides strong guarantees: each transaction sees a consistent snapshot of the data as it existed when the transaction began, preventing dirty reads, non-repeatable reads, and phantom reads . However, snapshot isolation can still permit a specific anomaly called write skew, which is not possible under true serializable isolation . MongoDB offers serializable-like behavior through transactions with specific configurations, but this is not the default mode.
Write skew is a subtle anomaly that snapshot isolation allows but serializable isolation prevents. Consider two bank accounts held by the same customer with a rule that the combined balance must never be negative. With snapshot isolation, two concurrent transactions could each read both account balances (seeing the same initial snapshot), then each withdraw money from different accounts, assuming the combined balance rule is satisfied. Both transactions can commit because they updated different documents, resulting in a final state where the combined balance is negative - something that could not happen in any serial order . This is the write skew anomaly.
Snapshot isolation gives each transaction a consistent snapshot at start time; transactions don't see each other's uncommitted changes
Serializable isolation ensures transaction execution is equivalent to some serial order, preventing all anomalies including write skew
MongoDB uses snapshot isolation for all multi-document transactions; you cannot select different isolation levels like in SQL databases
To approach serializable behavior in MongoDB, use transactions with
readConcern: "snapshot"andwriteConcern: "majority", plus careful conflict handlingEven with these settings, MongoDB's isolation is not equivalent to strict serializability in all distributed scenarios
MongoDB intentionally simplifies the model by using snapshot isolation consistently rather than offering multiple SQL-style isolation levels . You control consistency through read concerns (local, majority, snapshot, linearizable) rather than switching isolation levels. For most business-critical operations, snapshot isolation with majority writes provides strong guarantees while maintaining good concurrency. If your application requires protection against write skew, you must design transactions carefully to detect and handle these conflicts, typically by including all related documents in the same transaction or using application-level locking.