Total count strategies for paginated UIs
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-21 · skill ranked-a7641cd8
↓ Facts as markdownall context files
Source-anchored research for Total count strategies for paginated UIs. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- When a UI needs the exact number of documents matching its active filters, use `countDocuments(filter)` independently of the page fetch. MongoDB defines it as counting query matches, and Mongoose's pagination example runs `find(filter)` and `countDocuments(filter)` in parallel. (high confidence) [source]
- For sequential cursor or keyset interfaces, an exact total is optional: cursor pagination does not track a page position, and computing a separate exact count adds work. A continuation cue or approximate total can suit feeds and load-more UIs; offset pagination remains useful when users need arbitrary page jumps. (high confidence) [source]
Problems, failure modes and limitations
- `estimatedDocumentCount()` reads collection metadata and does not accept a query filter. It is faster than an accurate count, so it can provide a rough unfiltered collection total but cannot provide the filtered total for a search or list view. (high confidence) [source]
- $facet can return a page branch and a count branch from the same aggregation input. The page branch's $skip/$limit does not cap the count branch, which must count all documents that pass the preceding filter; one aggregation request therefore does not make an exact total free. (high confidence) [source]
- MongoDB limits each `$facet` stage's result to 100 MB, does not let `allowDiskUse` lift that limit, and still applies the 16 MiB BSON limit to the final output document. (low confidence) [source]
Facts and statements
- Published workload reports do not establish a universal latency winner between $facet and separate page/count operations: a .NET benchmark reported the separate path faster, its author reported $facet faster in a JavaScript shell, and a later test found the winner changed with whether its filter was indexed. Benchmark the actual pipeline, driver, and indexes. (medium confidence) [source]
- If the interface needs only a next-page indicator, request pageSize + 1 results, return the first pageSize, and set hasNext from whether the extra result exists. This avoids computing a full total and total-page count. (medium confidence) [source]
- For a frequently read total over a well-defined subset, a cached or maintained counter can replace repeated counting, but writes must update it and the application should periodically reconcile it against the collection count. (medium confidence) [source]
- For an exact unfiltered collection count, `countDocuments({})` can perform a full collection scan. MongoDB documents an `_id_` index hint or an `_id >= MinKey` predicate as ways to use an index for this empty-filter case. (high confidence) [source]
Children
- hasNextPage without computing total pages (frontier)
- Maintained or cached count counters (frontier)
- Count consistency under concurrent writes (frontier)
Frontier under this node: Count consistency under concurrent writes, Maintained or cached count counters, hasNextPage without computing total pages