What is the difference between MongoDB's readConcern levels local, majority and linearizable?

## Read concern versus read preference These are two independent dials that beginners conflate. **Read preference** chooses *which member* answers. **Read concern** chooses *which version of the data* that member may show you. You can send a `majority` read to a secondary, or a `local` read to the primary; the combination is what determines what you actually see. ## `local` The default for most reads. The member returns the most recent data it has, with no check on whether that data has replicated anywhere else. On a primary this is the freshest possible view. Its weakness is precise: a write that has been applied on the primary but has not yet reached a majority is visible, and if the primary steps down before that write becomes majority-committed, the write is discarded during rollback — so a client can genuinely read a value that later ceases to have ever existed. That is acceptable for most application reads and unacceptable for a read whose result triggers an external, irreversible action such as shipping goods or calling a payment API. ## `available` A close relative of `local`, relevant on sharded clusters. It behaves like `local` but skips the extra work of filtering out orphaned documents — documents left on a shard after a chunk migration. It offers the lowest latency and the weakest guarantee, and it can return duplicates for documents in flight between shards. It is not usable with causally consistent sessions. ## `majority` The member returns only data that has been acknowledged by a majority of the set — the **majority commit point**. Nothing you read at this level can be rolled back later. The subtlety that catches people: `majority` is a *durability* filter, not a *freshness* guarantee. Each member maintains its own view of what is majority-committed, so a `majority` read on a lagging secondary can be well behind, and even on the primary a `majority` read can be slightly behind the primary's newest local writes, because those writes have not yet been confirmed by other members. "Cannot be rolled back" and "is the newest value" are different properties, and `majority` gives only the first. In currently-shipping versions majority read concern is always available and cannot be disabled. ## `linearizable` The strongest level, and the most constrained: - It is accepted **only on the primary** — it cannot be combined with a read preference that allows secondaries. - Its guarantee applies to a query filter that **uniquely identifies a single document**; it is not a level for range scans or aggregations. - It is not usable inside multi-document transactions. Before returning, the primary confirms that prior writes have been majority-committed and that it has not been superseded — in effect proving it is still the primary at the moment of the read. That makes the result reflect the real-time ordering of writes, which `majority` alone does not: with `majority` you could read from a member that has not learned about a newer, already-committed write. The cost is a round trip to a majority of members on the read path, and a read that can block indefinitely if the primary cannot reach a majority. **Always pair it with `maxTimeMS`.** Reserve it for the handful of reads that genuinely need a real-time answer, such as a leader-election check or a critical uniqueness test. ## `snapshot` Reads from a single, consistent point-in-time view of majority-committed data, so multiple reads see one coherent state rather than a moving target. Its natural home is multi-document transactions, and recent versions also allow it on certain read commands outside transactions, optionally pinned to a specific cluster time. A snapshot may be slightly behind the newest data by design — consistency across the read, not maximal freshness, is the point. ## Choosing A workable default policy: - Ordinary application reads: `local` (the default) is fine. - Reads that gate an irreversible action, or that must not show data a failover could erase: `majority`. - A read that must reflect the true current state in real time, matched on a unique key: `linearizable`, with a timeout, used sparingly. - Multiple related reads that must agree with each other: `snapshot`. And remember the interaction with read preference: `majority` on a secondary bounds durability but not staleness. If freshness is what you actually need, that is a question of where you read and whether you are using a causally consistent session, not of raising the read concern level.