Read Concern
Parent: MongoDB Connection String URI · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-67b8def68c5a
↓ Facts as markdownall context files
Source-anchored research for Read Concern. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- With read concern `linearizable`, reads on the primary return data reflecting successful majority-acknowledged writes completed before the read begins and may wait for concurrent writes to propagate to a majority. MongoDB does not support this level in transactions or causally consistent sessions. The guarantee applies only when the query filter uniquely identifies one document. A consistent snapshot is not assured unless the search key is immutable, no concurrent update mutates that key, or the query uses a unique index on the search key. MongoDB recommends `maxTimeMS` to bound waits when a majority of data-bearing members are unavailable; Percona's MongoDB 3.4 review describes the same before-read guarantee. (high confidence) [source]
- MongoDB documents local as the default for reads against the primary and secondaries, but operations inherit a configured global default when one exists. Local reads have no guarantee that returned data has reached majority commit, so the data may later roll back. (high confidence) (verified as of 2026-10-14) [source]
Problems, failure modes and limitations
- The MongoDB URI options page exposes readConcernLevel and lists local, majority, linearizable, and available. It says mongosh cannot use this connection-string option and directs shell users to specify read concern on supported operations. The separate server reference supports snapshot reads in transactions and selected commands, so do not infer the full server read-concern level set from the URI option table. (high confidence) (verified as of 2026-10-22) [source]
- Majority read concern returns data from the majority-commit point, so it excludes writes that have not reached majority commitment, but it does not promise the latest system state. MongoDB warns that a node's latest data may lag the system, and Percona describes a PSA deployment where majority reads on the primary do not show newer data while the majority commit point cannot advance. (high confidence) (verified as of 2026-10-22) [source]
Facts and statements
- The URI option is `readConcernLevel` (for example, `?readConcernLevel=majority`). MongoDB's connection-string manual lists `local`, `majority`, `linearizable`, and `available` as its levels and says this option is unavailable in `mongosh`; the driver URI specification describes it as the client's default read concern. (high confidence) (verified as of 2026-10-22) [source]
- If a URI omits `readConcernLevel`, the Go driver's client read concern remains unset and the driver uses the server-configured default. The driver specification distinguishes an unspecified read concern from an explicit `local` level. (high confidence) [source]
- `local` can return data from the queried node that has not been majority committed and may later roll back. `majority` reads from the majority-commit point and protects returned data from rollback, but MongoDB warns that a node's newest data may still lag the newest system state. (high confidence) [source]
- Read concern `snapshot` returns majority-committed data as of a single point in time in the recent past. For multi-document transactions, this guarantee applies only if the transaction commits with `writeConcern: "majority"`. Outside multi-document transactions, MongoDB supports `snapshot` for `find`, `aggregate`, and `distinct` on unsharded collections; a read that exceeds `minSnapshotHistoryWindowInSeconds` may terminate. (high confidence) (verified as of 2026-10-23) [source]
- MongoDB guarantees transaction-level `majority` and `snapshot` reads only if the transaction commits with `writeConcern: "majority"`. Jepsen's MongoDB 3.6.4 analysis records historical confusion about weaker levels in causal sessions and says MongoDB later added documentation warnings; do not generalize that tested-version report to current versions without rechecking. (medium confidence) [source]
- Within a multi-document transaction, read concern is set at transaction level. Snapshot provides a point-in-time view of majority-committed data across shards, but that guarantee applies only if the transaction commits with write concern majority. In causally consistent sessions, the snapshot also includes causal history preceding transaction start. (high confidence) [source]
- Jepsen's evaluation of MongoDB 4.2.6 reports stale reads in configurations without linearizable read concern. This is historical, version-specific evidence from its 2020-05-15 report and does not establish behavior in current releases. (low confidence) (verified as of 2020-05-15) [source]
Children
- No children recorded.