# Find projection vs $project aggregation coverage > Source-anchored research for Find projection vs $project aggregation coverage. 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/) · 5 facets · 18 facts · page: https://llms-explorer.com/tree/find-projection-vs-project-aggregation-coverage/ ## Definitions - A narrow scalar example is an index {sensorId: 1, ts: -1} serving an equality filter on sensorId, descending ts order, and projection {sensorId: 1, ts: 1, _id: 0}; adding a requested field absent from that index requires fetching documents. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization/) ## How it works - Projection reduces returned data and network traffic, but document reads disappear only when a covered plan can answer the query from an index; an IXSCAN followed by FETCH still reads collection documents. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization/) - For ordinary scalar-field coverage, the fields needed by the query and the returned fields must be available from the same index. Explicitly exclude _id when it is absent from that index; an index that includes _id can instead return it without violating this requirement. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization/) - find() and $project include _id by default. If the candidate covering index omits _id, explicitly project _id: 0; otherwise retrieving _id can force a document fetch even when every other requested field is indexed. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization/) - Verify coverage with explain execution statistics and the actual winning plan: an index-only plan has no document-fetch ancestor of its index scan, and totalDocsExamined should be zero. An IXSCAN by itself is insufficient because a FETCH can sit above it. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/explain-results/) ## Problems, failure modes and limitations - A $match filter independent of projected computations can move ahead of projection stages; a filter on a computed result cannot simply move before the stage that computes it. This constrains assumptions about index access when shaping output. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/aggregation-pipeline-optimization/) - find() sorts on original field values before applying projection. Aggregation stage order and optimizer dependencies matter: a $sort preceded by $project can lose index-backed sorting, and moving a computed projection across sort plus limit can change which documents raise errors. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/) - In its update dated 2026-10-22, SERVER-135176 reports a presence-sensitive aggregation example where projection pushdown makes an indexed pipeline return $type as null for a missing field; the index-free pipeline returns missing. The report does not identify affected or fixed release versions, so it cannot establish a release-wide exposure range. (low confidence) (verified as of 2026-10-22) — [source](https://jira.mongodb.org/browse/SERVER-135176) ## Comparisons and alternatives - For the scalar inclusion examples, explain("executionStats") distinguishes PROJECTION_COVERED over IXSCAN with totalDocsExamined: 0 from a projection over FETCH and IXSCAN with positive document examinations. Inspect actual executions with matching data rather than equating index use with coverage. (high confidence) — [source](https://blog.frogred8.dev/docs_en/023_mongodb_covered_query/) - MongoDB issue SERVER-134945 reports a reproducer where adding $count enables covered input and changes a downstream missing-field match result because an absent indexed path is materialized as null. Treat this as a reported correctness edge case, and verify missing-versus-null behavior on the deployed build rather than generalizing it to all versions. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-134945) - SERVER-54128 documents a historical correctness bug where a computed projection pushed before sort plus limit could raise an error on a document that the original pipeline would discard. The issue describes pushing required input fields instead of eagerly evaluating the computed projection. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-54128) ## Facts and statements - Aggregation can also use a covering index for its input-stage query. Coverage is a property of the optimized dependencies and selected plan, so replacing find projection with $project does not by itself establish or eliminate coverage. The API comparison is an inference from the documented find coverage rules and aggregation index support. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization/) - Current documented find projection accepts aggregation expressions, including computing new fields and replacing existing field values. The older blanket distinction that only aggregation $project can compute output fields is therefore inaccurate. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/) - Both find projection and aggregation $project support inclusion, exclusion, computed values, and default inclusion of _id. Their overlapping output capabilities do not guarantee identical execution plans. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/) - MongoDB automatically determines the subset of document fields needed by an aggregation pipeline. Adding an early or middle $project solely to reduce fields passed downstream is usually unlikely to improve performance; $project typically belongs at the end to select client output. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/aggregation-pipeline-optimization/) - A production write-up traced unnecessary document reads to a Spring Data include projection that implicitly retained _id. Explicitly excluding _id removed the document-fetch work, while repeated index values still crossed the network; coverage alone did not remove that remaining work. (medium confidence) — [source](https://www.devadvisor.io/blog/08-2026_mongodb-distinct-scan-covered-index/) - A covered query obtains its predicate inputs and returned fields from the same index without examining collection documents. All required fields, including fields needed internally, must be available; null-equality predicates are a documented restriction. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization/) - Since MongoDB 4.4, find projections accept aggregation expressions and can create or replace output fields. An old statement that computed projections require the $project pipeline stage is not a valid modern API distinction. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.find/)