Find projection vs $project aggregation coverage
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-24
↓ Facts as markdownall context files
Source-anchored research for Find projection vs $project aggregation coverage. 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.
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]
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]
- 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]
- 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]
- 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]
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]
- 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]
- 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]
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]
- 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]
- 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]
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]
- 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]
- 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]
- 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]
- 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]
- 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]
- 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]
Children
- No children recorded.