# available read concern > Source-anchored research for available read concern. Run status: COMPLETED. Parent: [Read Concern Levels](https://llms-explorer.com/tree/read-concern-levels/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/available-read-concern/ ## How-to and procedures - To request this level explicitly, supported read commands use readConcern: { level: "available" }; the client URI option readConcernLevel controls the default read concern and is separate from readPreference, which controls server selection. (high confidence) — [source](https://github.com/mongodb/specifications/blob/master/source/read-write-concern/read-write-concern.md) ## Problems, failure modes and limitations - "available" cannot be used with causally consistent sessions or transactions. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) ## Comparisons and alternatives - MongoDB documentation lists local as the default for reads against both primaries and secondaries. Treat available as an explicit choice rather than assuming secondary reads select it. Deployment or client settings can override defaults. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/reference/mongodb-defaults/) ## Facts and statements - Read concern "available" returns data from the serving instance without guaranteeing majority replication; returned data may subsequently be rolled back. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - For sharded collections, "available" avoids checks that the query reached the authoritative shard and avoids waiting for routing metadata refreshes. This improves partition tolerance but can return orphaned documents or stale data from a migrated chunk. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - For unsharded collections, including standalone and replica set deployments, "available" and "local" behave identically. Choosing "available" alone therefore adds no distinct unsharded read semantics to an Atlas deployment. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - The performance benefit is conditional: implementation notes describe potentially faster reads by avoiding metadata-refresh communication, not a quantified cross-cloud latency improvement or an unconditional ability to serve every read during a partition. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) - SERVER-69219 documents using "available" to find unowned documents, but a shard-key equality predicate can target only some shards and miss unowned documents elsewhere. The issue describes an aggregation with {$replaceWith: "$$ROOT"} as a workaround; this is historical troubleshooting evidence, not a verified recipe for every current server release. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-69219) - The 2019 MongoDB-authored paper Tunable Consistency in MongoDB explicitly leaves the sharding-specific guarantees of "available" outside its discussion; its consistency and performance discussion should not be treated as validation of this level in multi-cloud sharded deployments. (low confidence) — [source](https://www.vldb.org/pvldb/vol12/p2071-schultz.pdf) - ApsaraDB for MongoDB documentation dated June 2, 2026 calls "available" the default for reads against secondaries in a sharded cluster. Current MongoDB default-setting documentation lists "local" for secondary reads, so the ApsaraDB-specific statement should not be generalized into an Atlas default. (medium confidence) (verified as of 2026-06-02) — [source](https://www.alibabacloud.com/help/en/mongodb/use-cases/transactions-and-read-write-concern) - For reads of sharded collections on secondary shard nodes, available avoids waiting for routing-table cache refreshes that local may require. This can reduce latency and tolerate metadata-service partitions, but stale routing can expose orphaned documents or an obsolete chunk view. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - Reading the newest data present on one node does not establish that it is the newest data in the system; available provides no guarantee of globally fresh results. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md) - Mongoose Query.readConcern('available') sets the query read concern; Query.readConcern('a') is its documented alias. (low confidence) (verified as of 2026-10-20) — [source](https://mongoosejs.com/docs/api/query.html) - For Atlas Multi-Cloud applications, using available as an availability optimization requires accepting rollback and, for sharded collections, ownership-related anomalies. This is an application-design inference from server semantics, not an Atlas-specific failover or latency guarantee. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-available.md)