beginnerintermediateadvanced

MongoDB · Read Concern and Write Concern

Read Concern and Write Concern

The two knobs that trade latency and availability for durability and consistency guarantees

w: "majority"safe against a single primary failure — the same majority elects the next primary
j: truesurvives a crash-and-restart, not just an in-memory apply
readConcern "majority"guaranteed never to be rolled back — may lag the absolute latest write
No free guaranteeevery stronger setting costs latency, and availability under a partition

1.Write concern: acknowledgement and durability

Write concern controls how many replica set members must confirm a write before MongoDB reports it as successful. A weaker write concern returns faster but risks that acknowledged write later being rolled back if the primary fails before it replicates; a stronger one waits longer but makes that outcome far less likely.

Key features

w: 1 (default in many driver configurations) acknowledges once the primary itself has applied the write — fastest, but a primary failure before replication can lose it
w: "majority" acknowledges once a majority of voting members have applied it — safe against a single primary failure, because a new primary is elected from that same majority
w: <n> acknowledges once n members have applied it — a middle ground, but not automatically tied to what an election requires the way "majority" is
journal (j: true) additionally requires the acknowledging member(s) to have written to their on-disk journal, surviving a process crash and restart on that member
A stronger write concern trades latency for a lower probability of losing an acknowledged write — never a difference in what gets written, only in when success is reported and how safe that report is

w: 1 vs. w: "majority"

w: 1

primary applies the write, acknowledges immediately
fastest response
if the primary fails before replicating, the write can be lost on failover

w: "majority"

waits for a majority of members to apply it
higher latency
safe against single-primary failure — a new primary is elected from that same majority

Command

text

{ writeConcern: { w: 1 | "majority" | <n>, j: true | false, wtimeout: <ms> } }

Write concern trades latency for the durability of an acknowledged write — w: "majority" is safe against a single primary failure because a new primary is always elected from that same majority.

2.w, j, and wtimeout

A write concern has three independent settings: w (how many members must acknowledge), j (whether acknowledgement requires an on-disk journal write, not just an in-memory apply), and wtimeout (how long to wait before giving up on the requested w and j).

Key features

w: 1 / "majority" / <n> — how many members must apply the write before acknowledging
j: true — additionally requires the acknowledging member(s) to have the write durably in their on-disk journal, surviving a crash-and-restart on that member
j: false (or omitted, depending on version/config) — acknowledgement can happen once the write is applied in memory, before the journal flush
wtimeout: <ms> — if the requested w/j is not satisfied within this time, the write returns an error, though the write itself is not undone
A write concern error (timeout) does not mean the write failed to apply anywhere — it means the requested acknowledgement level was not confirmed in time

The three write concern dials

The three write concern dials
Setting	Controls	Typical production value
w	how many members must acknowledge	"majority"
j	whether acknowledgement requires on-disk durability	true
wtimeout	how long to wait before giving up	a few seconds, application-dependent

Command

text

{ writeConcern: { w, j, wtimeout } }

w, j, and wtimeout are three independent dials — how many copies, how durable each copy is, and how long to wait. A write concern timeout means "not confirmed in time," not "did not happen."

3.readConcern levels

readConcern controls how "safe" the data a read returns is — whether it might include data that could still be rolled back, or is guaranteed to have been durably committed to a majority of the replica set before the read ever saw it.

Key features

local (the default for most reads) returns the queried node's current data, which can include writes not yet acknowledged by a majority
majority returns only data acknowledged by a majority of the replica set — guaranteed never to be rolled back on a subsequent election
linearizable, for single-document reads, guarantees the read reflects the most recent majority-committed write, with an added latency cost
snapshot, primarily used inside transactions, gives a consistent point-in-time view across multiple reads
A stronger read concern can return slightly older data if that is what is currently majority-confirmed — it trades recency for the guarantee of non-rollback, not the other way around

Read concern, from weakest to strongest guarantee

local

whatever this node currently has — fastest, could still be rolled back

majority

only majority-committed data — guaranteed durable, never rolled back

linearizable

majority, plus guaranteed to reflect the latest committed write

Command

text

{ readConcern: { level: "local" | "majority" | "linearizable" | "snapshot" } }

local is fast but can return data that could still roll back; majority guarantees durable, never-rolled-back data, possibly slightly behind the absolute latest write; linearizable adds the "latest write" guarantee on top, at more latency cost.

4.Choosing concern strength

A stronger read or write concern is not free — it costs latency, and under a network partition or member outage it can cost availability too, since "majority" cannot be satisfied if a majority is unreachable. The right choice matches the guarantee's cost to what is actually at risk without it.

Key features

Stronger write/read concern means waiting for more members to respond — direct added latency on every such operation
w: "majority" (and readConcern "majority") cannot be satisfied if a majority of voting members is unreachable — the operation blocks or times out rather than proceeding weakly
A weaker concern trades that safety for continuing to operate through a partial outage, at the cost of a small risk window
High-volume, low-stakes writes (telemetry, page views, logs) are usually fine at weaker concern — the aggregate cost of occasionally losing one is near zero
Financial, inventory, and anything gating an irreversible real-world action (shipping, granting access) usually justifies the stronger, slower guarantee

Command

text

// Ask: what actually happens if this specific write/read is wrong once? Scale concern strength to that answer.

Scale concern strength to what breaks if the weaker guarantee is wrong once — high-volume/low-stakes data can usually take the weaker, faster default; anything gating an irreversible action usually justifies the slower, safer one.

5.Consistency is a trade-off, not a free feature

Every read/write concern choice in this section is the same underlying trade-off in different clothes: more consistency costs latency and, under a partition, availability. There is no setting that gives stronger guarantees for free — the whole point of learning the individual knobs is to spend that cost deliberately instead of by accident.

Signature

consistency ↔ latency ↔ availability — pick two, deliberately, per operation

Read and write concern are not "correctness settings to max out" — they are a dial between consistency, latency, and availability, and the right position depends on what a given piece of data is actually worth protecting.

Spotted a mistake on this page? Tell us.

Read Sheet