# Read vs Write Distribution > Source-anchored research for Read vs Write Distribution. Run status: COMPLETED. Parent: [MongoDB Capacity Planning](https://llms-explorer.com/tree/mongodb-capacity-planning/) · 5 facets · 8 facts · page: https://llms-explorer.com/tree/read-vs-write-distribution/ ## Definitions - A read/write percentage is not a transferable MongoDB capacity multiplier: benchmark results depend on workload characteristics, query complexity, data and access patterns, and deployment configuration. (medium confidence) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/) ## How it works - MongoDB replica sets use the primary read preference by default, and writes go to the primary while secondaries replicate them. Routing reads to secondaries changes read placement but does not remove their write-application work. Because replication is asynchronous, secondary reads can return stale or non-monotonic results; fallback behavior can also send reads back to the primary when eligible secondaries are unavailable. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/core/read-preference-use-cases/) - MongoDB's read-preference guidance generally discourages using secondary or secondaryPreferred solely to add read capacity: replica-set members still handle roughly equivalent write traffic, secondary reads may be stale or non-monotonic, and member loss can leave the remaining members to serve all application requests. The guidance identifies dedicated ETL or reporting reads as a use for secondaries when the application accepts staleness. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference-use-cases/) ## Measurements and reference values - Percona reports that, in its PLGM setup, secondaryPreferred increased read capacity in an all-read scenario, while its separate mixed scenario with 46% writes showed almost no change in maximum throughput. The result is specific to those runs and does not establish a universal read/write threshold. (low confidence) (verified as of 2026-01-14) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/) - In benchANT's three-node, fully replicated MongoDB baseline using YCSB 0.17.0, ZIPFIAN reads, and insert-only writes, the page reports throughput variation of about ±5% between write-heavy and balanced mixes, while the 90%-read workload exceeded the 90%-write workload by more than 50%; these figures apply to that test setup. (low confidence) (verified as of 2026-10-23) — [source](https://benchant.com/blog/workload-read-write-ratio) ## Comparisons and alternatives - Include the workload's read/write mix and data-access pattern in capacity planning. benchANT's YCSB results varied with read/write mix and used a Zipfian access pattern; the authors also note that workload parameters and configuration affect the result. Percona independently reported different outcomes for read-only and mixed scenarios. These findings support using workload-specific evidence rather than a universal conversion factor. (medium confidence) — [source](https://benchant.com/blog/workload-read-write-ratio) - Percona's tested MongoDB cluster reached about 8,700 operations per second with a 54%-read, 46%-write workload versus about 13,600 operations per second in its 100%-find baseline, which Percona reported as roughly 35% lower capacity for that test. (low confidence) (verified as of 2026-01-14) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/) ## Facts and statements - Capacity tests should retain separate read and write throughput and latency measures: Percona reports average read and write latency for its mixed workload, and benchANT tracks read and write 95th-percentile latency as well as aggregate throughput. (medium confidence) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/)