# Count consistency under concurrent writes > Source-anchored research for Count consistency under concurrent writes. Run status: COMPLETED. Parent: [Total count strategies for paginated UIs](https://llms-explorer.com/tree/total-count-strategies-for-paginated-uis/) · 4 facets · 10 facts · page: https://llms-explorer.com/tree/count-consistency-under-concurrent-writes/ ## How it works - MongoDB silently ignores configured read concern for collections in the local database. Consequently adding readConcern: snapshot to a count or aggregate over local.oplog.rs does not provide the application-collection snapshot guarantee; this exception matters directly when interpreting oplog document counts during writes. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern/) ## Problems, failure modes and limitations - Counts taken from two actively changing copies at different applied timestamps can differ temporarily without proving data loss. Tencent's consistency-verification documentation explicitly describes this effect during ongoing writes; the methodological implication is to align the comparison point before interpreting a count mismatch as a correctness failure. (medium confidence) — [source](https://indonesia.tencentcloud.com/ind/document/product/571/61537) - Snapshot-based counting can fail if the needed history is no longer available. MongoDB bounds snapshot reads by minSnapshotHistoryWindowInSeconds, rejects atClusterTime values older than retained history, and warns that long snapshot reads may terminate. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot/) ## Comparisons and alternatives - MongoDB countDocuments counts matching documents through a $match/$group aggregation rather than collection metadata. Its documented accuracy after an unclean shutdown or with orphaned sharded documents must be distinguished from a guarantee of a point-in-time read under concurrent writes. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.countDocuments/) ## Facts and statements - An accurate document-counting method and a fixed point-in-time read are separate properties. MongoDB's replication README states that a non-snapshot read can continue on a newer snapshot after yielding, potentially skipping updated documents or observing some later updates. Therefore countDocuments() alone does not establish a fixed point-in-time count under concurrent writes. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) - For ordinary application collections, a count and a related read that must describe the same state should share a snapshot transaction, or explicitly use the same eligible snapshot timestamp. This is a methodological inference from snapshot semantics: independent reads without a shared timestamp can describe different database states. Set read concern at transaction level; snapshot transactions require majority write concern at commit for the documented majority-committed guarantees. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot/) - MongoDB documents snapshot read concern for aggregate and find outside multi-document transactions starting in version 5.0. An explicit aggregate count can therefore use snapshot read concern on an eligible application collection without requiring a multi-statement transaction; this does not mean the legacy count command supports snapshot read concern. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/read-concern-snapshot/) - Replacing metadata counts with document counts has an execution cost. An empty-filter countDocuments() performs a collection scan unless an appropriate index strategy is supplied; MongoDB illustrates hinting the _id index. Tencent likewise warns that document-count comparison can affect performance. An index improves the scan strategy but does not itself supply snapshot isolation. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.countDocuments/) - For a count that represents one point in time, use a supported aggregation with snapshot read concern, or countDocuments inside a transaction configured with snapshot read concern and committed with majority write concern. MongoDB documents countDocuments as transaction-capable; snapshot supplies the isolation guarantee. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.countDocuments/) - Majority read concern addresses majority-committed visibility; it should not be treated as synonymous with a shared snapshot for several count operations. Alibaba Cloud distinguishes majority-acknowledged reads from snapshot reads associated with a point in time, consistent with MongoDB documentation. (high confidence) — [source](https://www.alibabacloud.com/help/en/mongodb/use-cases/transactions-and-read-write-concern)