# majority-ack write concern change > Source-anchored research for majority-ack write concern change. Run status: COMPLETED. Parent: [MongoDB 8.0 performance changes & read-path regressions vs 7.0](https://llms-explorer.com/tree/mongodb-8-0-performance-changes-read-path-regressions-vs-7-0/) · 3 facets · 7 facts · page: https://llms-explorer.com/tree/majority-ack-write-concern-change/ ## 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](https://www.mongodb.com/docs/manual/reference/write-concern/) - 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](https://www.reddit.com/r/mongodb/comments/1to42d2/mongodb_80_broke_our_cache_refresh_stale_reads/) ## 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](https://www.percona.com/blog/mongodb-8-0-performance-does-it-live-up-to-the-hype/) ## 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](https://www.mongodb.com/docs/v8.0/reference/write-concern/) - 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](https://www.mongodb.com/docs/manual/reference/write-concern/) - 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](https://www.mongodb.com/docs/v8.0/reference/write-concern/) - 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](https://www.mongodb.com/company/blog/engineering/mongodb-8-0-improving-performance-avoiding-regressions)