Covered queries and projection design
Parent: Query Efficiency as a Cost Lever · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-9860e797131c
↓ Facts as markdownall context files
Source-anchored research for Covered queries and projection design. 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.
Structure and components
- An exclusion-only projection such as {_id: 0} does not declare a finite set of indexed return fields. Pachot demonstrates that it still needs FETCH even when the existing sample documents contain only indexed fields; use an explicit inclusion projection for that pattern. (medium confidence) [source]
How it works
- For a conventional secondary index that lacks _id, explicitly exclude _id with an inclusion projection such as {title: 1, _id: 0}; MongoDB otherwise returns _id by default and must fetch it. Alternatively include _id in the covering index when the application needs it. (high confidence) [source]
- Putting $project early merely to discard fields is unlikely to improve aggregation performance because MongoDB normally performs field-pruning optimization automatically. Use a final projection to define the client result, and verify whether the underlying access path is covered. (low confidence) [source]
Problems, failure modes and limitations
- The idealo slow-operations profiler documents grouping operations by projected fields and reporting response bytes, index keys read, and documents read. These metrics help separate smaller responses from avoided document reads. Its README labels `rDocs = 0` as covered, but a MongoDB Community Forum reply notes that `totalDocsExamined: 0` can also occur when no results match; inspect the explain output and confirm the query returns matches before treating zero document reads as evidence of coverage. (low confidence) [source]
Comparisons and alternatives
- Validate candidate coverage with explain("executionStats") on a query that actually returns matching data. Inspect totalDocsExamined and the complete plan: index-only examples examine zero documents, while an IXSCAN followed by FETCH still reads documents. PROJECTION_COVERED is useful evidence, but inspect actual execution rather than relying on a heading or index definition. (high confidence) [source]
- Adding indexes to obtain coverage increases write work because MongoDB updates indexes when it writes collection data. Target frequently used read paths and measure the read benefit against index maintenance rather than pursuing coverage for every query. (high confidence) [source]
- Coverage is a resource tradeoff rather than a guaranteed billing reduction: avoiding document fetches can reduce read work, while MongoDB must maintain added index fields during writes. Measure representative latency and resource use before deciding that a wider covering index is economical. (medium confidence) [source]
Facts and statements
- A covered query satisfies its predicates and returns its requested fields from the same index without examining collection documents. Design the index and projection together; indexing only the filter fields does not establish coverage. (high confidence) [source]
- Return only fields the application needs. A smaller projection reduces result payload and network traffic, but an ordinary noncovered projection can still fetch the full document before extracting those fields. (high confidence) [source]
- For scalar name values and an index {name: 1}, find({name: "Max"}, {_id: 0, name: 1}) is an illustrative covered query. An inclusion projection makes the required output fields explicit; merely excluding _id does not specify which other fields to return. (high confidence) [source]
- Compound multikey indexes can cover eligible queries that return non-array fields, provided the projection excludes the array field, the query has no $elemMatch, and the other coverage conditions hold. Returning the indexed array itself requires document access. (high confidence) [source]
- MongoDB documents equality-to-null predicates, including {field: null} and {field: {$eq: null}}, as ineligible for covered queries. Treat field membership in an index as necessary but insufficient. (low confidence) [source]
- Coverage does not guarantee a fast query: a nonselective predicate can still examine many index keys. Compare keys examined, documents examined, returned rows, and measured runtime before treating a projection/index change as an efficiency improvement. (high confidence) [source]
- Dot-notation indexes can cover predicates and projections on individual embedded scalar fields. Nested data alone does not rule out coverage; distinguish embedded scalar paths from array-valued paths. (medium confidence) [source]
- Ivanov’s 2026 study reports slower unbounded projection operations on MongoDB 8.2.5 than 6.0.3 across its tested collection sizes. This is evidence against universal projection-speed claims, not a measurement of covered-query gains: the study uses a synthetic e-commerce workload and isolated single-thread execution, so its timings do not directly establish production savings. (low confidence) (verified as of 2026-05-15) [source]
Children
- No children recorded.