# Read preference and write routing for cost > Source-anchored research for Read preference and write routing for cost. Run status: COMPLETED. Parent: [Atlas Cluster Topology and Tier Economics](https://llms-explorer.com/tree/atlas-cluster-topology-and-tier-economics/) · 4 facets · 9 facts · page: https://llms-explorer.com/tree/read-preference-and-write-routing-for-cost/ ## How it works - A dedicated secondary read path can isolate ETL or reporting queries from operational reads on the primary. MongoDB cautions that secondary reads are not a general read-capacity strategy because every member handles replicated write traffic, and sharding is often a better way to add total capacity. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference-use-cases/) - Non-primary read preferences can return stale results because replication is asynchronous, and reads from different secondaries may be non-monotonic. maxStalenessSeconds filters secondaries by driver-estimated lag; applications that need causal read-after-write guarantees should use causally consistent sessions with majority read and write concern. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference/) - MongoDB cautions against using secondary or secondaryPreferred as a general way to add read capacity: secondaries also apply roughly equivalent write traffic, and sending reads to them can reduce availability headroom when remaining members must handle the workload. MongoDB says sharding is often a better route to more overall read and write capacity; Datadog gives the same general caution. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/core/read-preference-use-cases/) - Because replication is asynchronous, non-primary reads can lag successful writes; reads from different secondaries may also be non-monotonic. Applications that route reads to secondaries should tolerate that consistency behavior or use the documented causal-consistency mechanisms. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference/) ## Measurements and reference values - Percona's January 2026 benchmark found no maximum-throughput gain from secondaryPreferred in one workload with 46% writes, while separate all-read runs reported higher throughput when reads moved to secondaries. These are setup-specific findings; they show that routing benefits depend on workload mix and bottleneck. (low confidence) (verified as of 2026-01-14) — [source](https://www.percona.com/blog/the-importance-of-realistic-benchmark-workloads/) ## Problems, failure modes and limitations - For dedicated ETL or reporting reads, MongoDB recommends secondary when primary spillover would make those queries compete with writes. secondaryPreferred can fall back to the primary when no secondary is eligible under its staleness or tag constraints, while secondary restricts reads to secondary members and can fail if none is eligible. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference/) ## Facts and statements - In a replica set, readPreference selects eligible members for reads and defaults to the current primary. Writes remain directed to the primary and then replicate to secondaries, so changing readPreference does not reroute writes or remove the cluster's replication work. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference/) - Replica-set tag sets can route reporting reads to selected members by purpose or location. Percona's 2018 guidance describes sending internal reports to lower-configuration secondaries and using tags for cost-effective cross-datacenter reads; this supports workload placement, but does not establish a specific Atlas bill reduction. (medium confidence) — [source](https://www.percona.com/blog/mongodb-replica-set-tag-sets/) - Atlas Online Archive is read-only and historical queries use a federated endpoint; keep writes directed to the live cluster. This is a separate historical-data route from replica-set read preference, and archived queries may be slower than live-cluster queries. (high confidence) — [source](https://www.mongodb.com/docs/atlas/online-archive/overview.md)