majority-ack write concern change
Parent: MongoDB 8.0 performance changes & read-path regressions vs 7.0 · Published reference · snapshot 2026-10-15 · viability 3.80 / 5 (research)
↓ Facts as markdownall context files
Depth-first rabbithole dossier for majority-ack write concern change; source-anchored research pack.
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.
Measurements and reference values
- [low] MongoDB 8.0 achieves 36% better read throughput and 56% faster bulk writes, with an independent applier thread increasing replication throughput by about 20% by asynchronously applying changes to the local database. (verified as of 2026-10-15) Sources: https://www.percona.com/blog/percona-server-for-mongodb-8-0-the-most-performant-ever/ [source]
- [high] MongoDB 8.0 introduces performance improvements over 7.0, including up to 36% better read throughput, up to 32% better performance for typical web applications, and up to 20% faster concurrent writes during replication. (verified as of 2026-10-15) Sources: https://www.mongodb.com/docs/manual/release-notes/8.0.md, https://www.mongodb.com/company/blog/engineering/mongodb-8-0-improving-performance-avoiding-regressions [source]
Problems, failure modes and limitations
- [low] If a write operation does not achieve the specified write concern within the wtimeout limit, MongoDB returns a write concern error but does not undo successful data modifications performed before the timeout; if wtimeout is not specified and the concern is unachievable, the operation blocks indefinitely. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
Comparisons and alternatives
- [high] Starting in MongoDB 8.0, write operations using the "majority" write concern return an acknowledgment when the majority of replica set members durably write the oplog entry, rather than waiting for the majority to apply the change as in previous releases. (verified as of 2026-10-15) Sources: https://www.mongodb.com/docs/manual/release-notes/8.0.md, https://www.mongodb.com/docs/manual/release-notes/8.0-compatibility.md, https://www.mongodb.com/docs/manual/reference/write-concern.md, https://www.mongodb.com/company/blog/engineering/mongodb-8-0-improving-performance-avoiding-regressions, h [source]
- [high] Because MongoDB 8.0 acknowledges majority writes upon durable oplog write rather than application, queries on secondaries immediately after a { w: "majority" } write acknowledgment may read data before the secondary applies the changes. (verified as of 2026-10-15) Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md, https://www.percona.com/blog/percona-server-for-mongodb-8-0-the-most-performant-ever/ [source]
- [high] In MongoDB 8.0, secondaries write and apply oplog entries for each batch in parallel, and insert operations for multi-document transactions are batched as a single oplog entry rather than producing individual entries. (verified as of 2026-10-15) Sources: https://www.mongodb.com/docs/manual/release-notes/8.0-compatibility.md, https://www.percona.com/blog/percona-server-for-mongodb-8-0-the-most-performant-ever/ [source]
Facts and statements
- [low] SERVER-91760, a test fix (txn_two_phase_commit_write_concern.js no longer assumes majority-committed writes are applied), was fixed in 8.1.0-rc0 and 8.0.0-rc10; the majority-ack change itself came from PM-3489. (verified as of 2026-10-15) Sources: https://jira.mongodb.org/browse/SERVER-91760 [source]
- [low] The default global write concern in MongoDB is majority, and on sharded clusters, DDL operations run with write concern "majority", overriding any specified different write concern. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
- [low] The voting majority of a replica set is calculated as 1 plus half the number of voting members rounded down; if the number of data-bearing voting members does not exceed this majority, the default write concern is { w: 1 }, otherwise it is { w: "majority" }. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
- [low] The local database in MongoDB does not support write concerns and silently ignores any configured write concern for operations on collections within it. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
- [low] Before MongoDB 5.0, the default write concern was w:1, returning a response as soon as the write was journaled to local disk, whereas with write concern majority, the server waits for a majority of nodes to write the document to disk before responding. (verified as of 2026-10-15) Sources: https://www.mongodb.com/company/blog/engineering/mongodb-8-0-improving-performance-avoiding-regressions [source]
- [low] Applications reading from secondaries that require immediate access to changes from { w: "majority" } writes in MongoDB 8.0 should run these operations in a causally consistent session. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
- [low] In MongoDB 8.0, if the calculated majority equals the number of all data-bearing voting members (e.g., a 3-member Primary-Secondary-Arbiter deployment), write concern "majority" may time out or never be acknowledged if a data-bearing voting member is down or unreachable. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
- [low] If writes use a { w: n } write concern where n is greater than the calculated majority, without journaling and with default cluster settings, MongoDB may acknowledge the write before it is durable on a majority of nodes. Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
- [low] Starting in MongoDB 5.0, replica set members in the STARTUP2 state do not participate in write majorities. Separately, with writeConcernMajorityJournalDefault set to false, "majority" writes could roll back after a transient loss (e.g. crash and restart) of a majority of nodes. (verified as of 2026-10-15) Sources: https://www.mongodb.com/docs/manual/reference/write-concern.md [source]
Related concepts
- write — is a part of majority-ack write concern change
- concern — is a part of majority-ack write concern change
- change — is a part of majority-ack write concern change
- majority-ack — is a part of majority-ack write concern change
Children
- No children recorded.