MongoDB does not offer a transaction setting literally named “isolation level.” For multi-document transactions, the closest control is transaction-level readConcern, which determines the read view the transaction uses. MongoDB supports local, majority, and snapshot; the guarantee you get also depends on commit write concern and whether the transaction runs on a sharded cluster.
How MongoDB transaction isolation works
MongoDB documents transaction read behavior through read concern rather than a named isolation-level option. A transaction’s read concern selects what data it can see while reading. Its write concern at commit affects the guarantees MongoDB documents for snapshot and majority reads.
Set read concern on the transaction. Within a transaction, collection-level and database-level read concern settings are ignored, as are read concern settings on individual operations. If the transaction does not specify a value, session- or client-level settings can apply. See MongoDB’s Read Concern documentation.
Choose a transaction read concern
| Transaction read concern | What it provides | Important qualification |
|---|---|---|
local |
Reads data available on the node; it does not require that the data be majority committed. | Do not treat it as a guarantee of a majority-committed point-in-time snapshot. |
majority |
Reads majority-committed data. | For the documented transaction guarantees, the transaction must commit with writeConcern: { w: "majority" }. It does not promise the newest possible data: a node’s latest data may lag the system’s most recent version. |
snapshot |
Reads majority-committed data from a specific point in time in the recent past. | For multi-document transactions, its documented guarantees require commit with writeConcern: { w: "majority" }. On a sharded cluster, this is the only listed choice that provides a consistent snapshot across multiple shards. |
MongoDB documents these options in Read Concern, with details for snapshot and majority on its version 8.0 manual pages. The guarantee is not determined by the read concern alone: check the transaction’s commit write concern and deployment topology too.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
Which option should you use?
For a consistent point-in-time view across shards
Use transaction-level readConcern: { level: "snapshot" } and commit with majority write concern. MongoDB documents snapshot as the only transaction read concern that provides a consistent snapshot across multiple shards. Consult the manual’s sharded-cluster production considerations for topology-specific behavior.
When majority-committed data is the requirement
majority is the relevant read concern when the requirement is to read majority-committed data rather than to request a point-in-time snapshot. For the transaction’s documented majority-read guarantees, commit with writeConcern: { w: "majority" }. This still does not mean the read returns the system’s newest possible data.
When considering local reads
local does not require majority-committed data. Use it only when that read view meets the application’s consistency needs; it is not interchangeable with the documented snapshot guarantee.
Configure and verify the transaction settings
The exact API call varies by driver, but the settings belong on the transaction and its commit. In driver pseudocode, the intent is:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →session.startTransaction({ readConcern: { level: "snapshot" } })
// Run the transaction's operations with this session.
session.commitTransaction({ writeConcern: { w: "majority" } })Use your driver’s documented transaction API and syntax rather than copying pseudocode as a drop-in command. Before relying on a guarantee, verify these settings:
- Transaction read concern: confirm the transaction specifies the intended level. Collection, database, and per-operation read concern settings do not set the transaction’s read view.
- Commit write concern: confirm whether the commit uses
{ w: "majority" }when relying on the documentedsnapshotor transactionalmajorityguarantees. - Inherited settings: if the transaction omits a value, inspect the effective session- or client-level read and write concerns. Transaction-level settings override those levels.
- Topology and server version: check whether the deployment is a replica set or sharded cluster, and compare its behavior with documentation for the deployed MongoDB version.
MongoDB’s documented implicit default write concern is majority in the ordinary case, but a replica set configured with an arbiter can have an implicit default of w: 1. Do not infer the commit guarantee from an assumed default; verify the effective deployment settings. See default read and write concerns.
Rank #4
Snapshot history and transaction duration
A snapshot read is tied to a point in the recent past, not an indefinitely retained historical version. MongoDB bounds snapshot history using minSnapshotHistoryWindowInSeconds. If a read lasts longer than the configured history window, it may terminate. Account for the configured window when evaluating long-running transactions; do not assume a fixed duration applies across deployments. Details appear in MongoDB’s snapshot read concern documentation.
Keep transaction snapshots distinct from causal consistency
Causal consistency addresses ordering across operations in a causally consistent session, not the transaction’s point-in-time read view. MongoDB documents that using majority reads and majority writes together in such sessions provides read-your-own-writes, monotonic reads, monotonic writes, and writes-follow-reads. Those guarantees are related to consistency, but they do not replace transaction-level read concern when choosing a snapshot. See Causal Consistency and Read and Write Concerns.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
