Read and Write Concerns
Read concern and write concern are MongoDB's tunable consistency knobs — they let you trade latency for durability/consistency guarantees on a per-operation basis, instead of a single fixed setting for the whole deployment.
Write Concern
Write concern controls how many replica set members must acknowledge a write before the driver considers it successful.
Option | Meaning |
|---|---|
| Only the primary must acknowledge — fastest, but a write can be lost if the primary fails before replicating |
| A majority of voting members must acknowledge — the write survives a primary failover |
| Exactly n members must acknowledge (rarely used directly; prefer majority) |
| The acknowledging member(s) must have written to their on-disk journal, not just memory |
| Milliseconds to wait for the requested acknowledgment before erroring out |
db.orders.insertOne(
{ customerId: id, total: 59.97 },
{ writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
)w: 1 without j: true acknowledges as soon as the primary applies the write to memory — a crash before the journal flush can lose that write even though the driver reported success. Use w: "majority" (the modern default in most drivers) for anything you cannot afford to lose.Read Concern
Read concern controls what durability/consistency guarantee the data returned by a read actually has.
Level | Guarantee |
|---|---|
| Returns the most recent data on the node being read, with no guarantee it has been replicated — it could later be rolled back after a failover |
| Similar to local, but on a sharded cluster returns data even from shards not fully migrated — lowest guarantee, used for max availability |
| Returns only data that has been acknowledged by a majority of the replica set — guaranteed not to be rolled back |
| Strongest single-document guarantee — reflects all writes acknowledged before the read began, at the cost of latency (primary-only) |
| Used within multi-document transactions — a consistent view of data as of a single point in time |
db.orders.find({ status: "shipped" }).readConcern("majority")Durability vs Latency Tradeoff
Every stronger guarantee costs latency, because the server (or the client) has to wait for more confirmation before responding.
Configuration | Latency | Guarantee |
|---|---|---|
w:1, readConcern: local | Lowest | Can lose acknowledged writes on failover; can read stale/rolled-back data |
w:majority, readConcern: local | Medium | Writes durable; reads may still see unreplicated data from local node |
w:majority, readConcern: majority | Higher | Both reads and writes reflect majority-acknowledged state — safe default for most apps |
w:majority, readConcern: linearizable | Highest | Strongest — real-time correctness for a single document, primary-only reads |
Causal Consistency Sessions
A causally consistent session guarantees that a client's own sequence of operations is observed in the order it performed them — read-your-own-writes — even if reads are routed to different secondaries. Without a session, a read immediately following your own write could land on a secondary that hasn't replicated it yet.
const session = client.startSession({ causalConsistency: true })
await db.collection("orders").insertOne(
{ status: "pending" },
{ session }
)
// Guaranteed to see the write above, even reading from a secondary,
// because both operations share the same causally consistent session
const order = await db.collection("orders").findOne(
{ status: "pending" },
{ session, readPreference: "secondary" }
)
await session.endSession()Sensible Defaults
Most applications:
writeConcern: { w: "majority" }andreadConcern: "local"(the modern driver default) — durable writes, fast reads.Financial/critical writes (balances, inventory decrements): add
j: trueand considerreadConcern: "majority"for the reads that drive decisions.Multi-document transactions: use
readConcern: "snapshot"withwriteConcern: "majority"for the transaction as a whole.Rarely reach for
linearizable— it is the most expensive guarantee and only applies to single-document reads on the primary; majority is enough for almost every real requirement.
Summary
Write concern (w, j, wtimeout) controls how many nodes must durably acknowledge a write.
Read concern (local/available/majority/linearizable/snapshot) controls what durability guarantee a read reflects.
Causal consistency sessions guarantee read-your-own-writes across replica set members.
w:majority + readConcern:majority is a safe, sensible default for most production workloads; reserve linearizable and heavier settings for genuinely critical paths.