<!-- llms-explorer concept facts · https://llms-explorer.com/tree/total-count-strategies-for-paginated-uis/ · pack 2026-10-21 · ~975 tokens -->

# Total count strategies for paginated UIs

> Source-anchored research for Total count strategies for paginated UIs. Run status: COMPLETED.

Parent: [MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting](https://llms-explorer.com/tree/mongodb-query-shape-optimization-sort-pagination-operators-and-sharded-targeting/) · 3 facets · 9 facts · page: https://llms-explorer.com/tree/total-count-strategies-for-paginated-uis/

## 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](https://www.mongodb.com/docs/manual/reference/method/db.collection.countDocuments/)
- 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](https://mongoosejs.com/docs/queries.html)

## 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](https://www.mongodb.com/docs/manual/reference/method/db.collection.estimatedDocumentCount/)
- $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](https://www.mongodb.com/docs/manual/reference/operator/aggregation/facet.md)
- 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](https://www.mongodb.com/docs/manual/reference/operator/aggregation/facet/)

## 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](https://www.mongodb.com/community/forums/t/paging-with-count-performance-facet-vs-simple-query/170806)
- 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](https://stackoverflow.com/questions/21803290/get-a-count-of-total-documents-with-mongodb-when-using-limit/53220591)
- 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](https://oneuptime.com/blog/post/2026-03-31-mongodb-index-for-count-operations/markdown)
- 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](https://www.mongodb.com/docs/manual/reference/method/db.collection.countDocuments/)
