majority-ack write concern change
Parent: MongoDB 8.0 performance changes & read-path regressions vs 7.0 · Published reference · snapshot 2026-10-23 · viability 3.80 / 5 (research)
↓ Facts as markdownall context files
Source-anchored research for majority-ack write concern change. Run status: COMPLETED.
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.
How it works
- Because acknowledgment can precede application on secondaries, an immediate secondary read after a majority acknowledgment may not include that write. Use a causally consistent session with majority read and write concerns when the application needs to read its own acknowledged write from a secondary. (high confidence) [source]
- A May 2026 Reddit operator report describes a cache-refresh flow where a service read from a secondary after a majority-acknowledged write and could receive stale data; replies discuss primary reads and causal sessions. Treat this as an anecdotal impact report, not a measure of incidence. (low confidence) (verified as of 2026-05-26) [source]
Measurements and reference values
- Percona's February 4, 2025 comparison of Percona Server for MongoDB 8.0.4 and 7.0.15 across eight mongo-perf cases reported average gains of 12%, 7%, and 9% at 1, 4, and 8 threads. The comparison spans full releases and multiple operations, so it does not isolate the majority-ack change's contribution. (medium confidence) (verified as of 2025-02-04) [source]
Facts and statements
- Starting in MongoDB 8.0, a { w: "majority" } replica-set write can be acknowledged once the calculated majority of data-bearing voting members durably writes the oplog entry; secondaries then apply the change asynchronously. Before 8.0, acknowledgment waited until the majority had applied the change. (high confidence) [source]
- MongoDB's current manual says the implicit default write concern is majority for most deployments, while MongoDB's 8.0 performance post says the default was w:1 before MongoDB 5.0. The 8.0 change is the acknowledgment point for majority writes, not the introduction of majority as the default. (high confidence) [source]
- With writeConcernMajorityJournalDefault set to true, MongoDB's default, { w: "majority" } acknowledgments wait for journal durability. If the setting is false, MongoDB can acknowledge before journal sync, and a transient loss or restart of a majority of replica-set members can roll back the write. (high confidence) (verified as of 2026-10-23) [source]
- By removing secondary collection-apply time from the acknowledgment wait, the design aims to reduce primary latency and improve majority-write throughput. MongoDB's engineering account reports a significant prototype boost, and Alibaba Cloud describes improved throughput; neither makes a workload-independent speedup guarantee. (medium confidence) [source]
Children
- No children recorded.