MongoDBadvanced

Write Concerns

Write concern, read concern and read preference — the three settings that decide MongoDB's durability and consistency per operation.

3 min readAdvancedUpdated 31 Jul 2026Edit this page

MongoDB

MongoDB's consistency is configured per operation through three independent settings. Getting them right is more consequential than most tuning.

Write concern

How many members must acknowledge a write before the driver returns.

Setting	Meaning	Loss on failover
`w: 0`	No acknowledgement at all	Anything
`w: 1`	The primary only	Writes not yet replicated
`w: "majority"`	A majority of voting members	None acknowledged
`j: true`	Written to the journal on disk	Adds crash durability
`wtimeout`	Milliseconds to wait before returning an error	—

db.orders.insertOne(doc, { writeConcern: { w: "majority", j: true, wtimeout: 5000 } });

wtimeout deserves care: on timeout the driver returns an error, but the write may still have been applied. Retry logic must therefore be idempotent.

Read Concerns

What the read is allowed to observe.

Level	Returns
`local`	The node's most recent data, which may later be rolled back
`available`	Like `local`, without waiting on shard metadata; can return orphaned documents
`majority`	Only data acknowledged by a majority — never rolled back
`linearizable`	Reflects all writes acknowledged before the read began (primary only)
`snapshot`	A consistent snapshot across the operation, used in transactions

db.orders.find({ _id: id }).readConcern("majority");

majority is what you want when a read informs a decision that cannot be undone. linearizable is stronger and much slower — it waits to confirm the node is still primary — and applies to single-document reads only.

Read Preferences

Which member serves the read.

Preference	Reads from
`primary`	Primary only (default)
`primaryPreferred`	Primary, or a secondary if none exists
`secondary`	Secondaries only
`secondaryPreferred`	Secondaries, or the primary if none available
`nearest`	Lowest network latency, primary or secondary

db.orders.find(query).readPref("secondaryPreferred", [{ region: "eu" }]);

Use maxStalenessSeconds to stop reads going to a badly lagging member:

db.orders.find(query).readPref("secondary", null, { maxStalenessSeconds: 90 });

Secondary reads break read-your-writes

Writing to the primary and immediately reading from a secondary can return the previous value. Either read from the primary for operations that follow a write, or use a causally consistent session, which makes the read wait for the session's own writes:

const session = client.startSession({ causalConsistency: true });

Choosing per operation

Operation	Reasonable setting
Payment or order state change	`w: "majority", j: true`, read from primary
User profile update then display	`w: "majority"`, causally consistent session
Product list, catalogue browse	`w: "majority"` on write, `secondaryPreferred` read
Analytics and reporting	`secondary` with `maxStalenessSeconds`
High-volume telemetry	`w: 1` on write, if losing recent points is acceptable

Set the strict values where correctness depends on them and the relaxed ones elsewhere, rather than choosing one global setting and hoping it suits everything.