Adds new computed fields to documents. Can use expressions to calculate field values based on existing fields.

Categorizes documents into buckets based on specified boundaries. Performs histogram-like grouping with explicit bucket ranges.

Automatically categorizes documents into specified number of buckets. MongoDB determines bucket boundaries to evenly distribute documents.

Returns change stream cursor for real-time data changes. Monitors insert, update, delete, and replace operations on collections.

Returns statistics about collection or view including storage stats, count, and index details.

Counts number of documents in pipeline and returns single document with count. Equivalent to { $group: { _id: null, count: { $sum: 1 } } }.

Returns information about active operations on MongoDB instance. Useful for monitoring and diagnosing performance issues.

Internal stage that represents the cursor reading documents from a collection. Appears in aggregation explain output when MongoDB optimizes the pipeline by pushing filters and projections to the query layer.

Fills gaps in time series data by creating documents for missing intervals. Generates synthetic documents to create continuous time series.

Creates documents from literal values specified in pipeline. Useful for testing or generating synthetic data without collection.

Processes multiple aggregation pipelines within single stage on same input. Returns object with results from each pipeline as separate arrays.

Fills null or missing field values using specified fill methods. Supports forward fill, backward fill, and linear interpolation.

Returns documents in order of proximity to geospatial point. Adds calculated distance field and must be first stage in pipeline.

Performs recursive graph traversal for hierarchical data. Useful for organizational charts, social networks, and parent-child relationships.

Groups documents by specified _id expression and computes aggregations. Similar to SQL GROUP BY clause.

Returns statistics about index usage for collection. Shows how often each index has been accessed since server start.

Limits number of documents passed to next stage in pipeline. Returns only first N documents from previous stage.

Returns catalog information for collections and views in a database. Provides metadata about collection options, indexes, and storage details.

Lists active sessions on current server only. Returns session information including users, connection details, and activity.

Returns information about existing Atlas Search indexes on a collection. Can filter by index name or return all indexes.

Lists all active sessions across entire cluster. Returns session information for all connected clients.

Performs left outer join with another collection to combine documents. Adds matched documents from joined collection as array field.

Filters documents in aggregation pipeline. Functions like find() queries - only passes documents matching specified conditions to next stage.

Merges aggregation results into output collection. Can insert new documents, replace existing ones, or merge fields.

Writes aggregation results to specified collection, replacing existing collection. Must be last stage in pipeline.

Returns plan cache information for collection. Shows cached query plans and their performance statistics.

Reshapes documents by selecting, excluding, or computing fields. Can include/exclude fields, rename fields, or add computed fields using expressions.

Restricts document content based on document-level access control. Recursively evaluates conditions to prune, descend, or keep document fields.

Replaces input document with specified document, promoting embedded document to top level. Useful for restructuring documents or promoting nested fields.

Alias for $replaceRoot. Replaces input document with the specified document. Shorthand syntax that takes an expression directly instead of {newRoot: <expression>}.

Randomly selects specified number of documents from input. Uses different algorithms based on sample size and collection characteristics.

Performs full-text search using Atlas Search indexes. Supports fuzzy matching, autocomplete, scoring, and facets.

Returns metadata about Atlas Search query execution without returning documents. Useful for getting facet counts and search statistics.

Sets or modifies field values in documents. Alias for $addFields introduced in MongoDB 4.2. Can add new fields or overwrite existing ones using expressions.

Performs window function operations like running totals, moving averages, and rankings. Partitions documents and computes aggregations over sliding windows.

Skips specified number of documents and passes remaining documents to next stage. Often used with $limit for pagination.

Sorts documents in aggregation pipeline by specified fields. Can sort in ascending or descending order on multiple fields.

Groups documents by expression and sorts by count in descending order. Shorthand for { $group: { _id: <expression>, count: { $sum: 1 } }, $sort: { count: -1 } }.

Combines results from current pipeline with documents from another collection. Similar to SQL UNION ALL operation.

Removes specified fields from documents. Shorthand for exclusion projection using $project.

Deconstructs array field into separate documents - one document per array element. Useful for denormalizing arrays and aggregating array elements.

Performs vector similarity search on vector embeddings for AI/ML applications. Finds semantically similar documents using vector indexes.

Evaluates accumulator expressions in aggregate context. Similar to project but maintains state across evaluations for accumulators.

Non-blocking streaming stage. Evaluates stateful accumulator expressions per row. Unlike regular project (stateless), this maintains accumulator state. Each accumulator has init and aggregate expressions. Used for aggregation operations that can be computed row-by-row.

The query planner selects a hash-based index intersection to combine results from multiple index scans. Builds a hash table from the first child and probes it with remaining children.

Non-blocking streaming stage but requires buffering first child in memory. Uses hash table (32MB default limit) to intersect RecordIds. Efficient for moderate result sets with good RecordId distribution.

Intersects results from N children using a hash table based on RecordId. Builds hash table from first child, then probes with remaining children.

Non-blocking streaming stage but requires buffering first child in memory. Uses hash table (32MB default limit) to intersect RecordIds from multiple children. Memory usage tracked but no disk spilling - fails if limit exceeded. Efficient for moderate result sets with good RecordId distribution.

The query planner selects a sorted index intersection to combine results from multiple index scans. Advances through sorted streams of RecordIds in lockstep to find matches.

Non-blocking streaming stage. Very memory-efficient — no buffering required. Requires pre-sorted inputs (typically from index scans). Performance depends on selectivity and number of children.

Intersects sorted result sets by advancing through sorted streams of RecordIds. Assumes each child produces RecordIds in sorted order.

Non-blocking streaming stage. Advances children in lockstep to find matching RecordIds. Very memory-efficient - no buffering required. Requires pre-sorted inputs (typically from index scans). Performance depends on selectivity and number of children.

The query planner selects a batched delete strategy for efficient multi-document removal. Groups delete operations into batches to reduce lock contention.

Non-blocking write stage with batching optimization. More efficient than individual deletes for bulk operations. Yields periodically to allow other operations.

Performs deletion operations in batches to improve performance and reduce lock contention. Introduced in MongoDB 6.1 for efficient multi-document deletes.

Non-blocking write stage with batching optimization. Groups multiple delete operations into batches to reduce write lock overhead. More efficient than individual deletes for bulk operations. Yields periodically to allow other operations to acquire locks. Introduced in MongoDB 6.1 specifically to improve multi-document delete performance. Particularly beneficial for deleting large numbers of documents.

Block-processing version of hash aggregation for columnar data. Processes data in blocks for improved performance with columnar formats.

Blocking stage that must consume all input before producing output. Can spill to disk when memory limit is exceeded (default 100MB). Works on blocks instead of individual rows for better cache locality. Only supports algebraic accumulators (median not supported). Two processing modes: tokenized (few unique keys) or element-wise (many unique keys). Optimized for columnar and time-series workloads.

Converts block-based columnar data to row-based format. Deblocks values from ValueBlocks or CellBlocks into individual row values.

Non-blocking streaming stage. Extracts individual values from blocks one at a time. All input blocks must be same size. Supports optional bitmap filtering. Used to transition from block processing to row processing. Memory for deblocked values owned by the input blocks.

Conditional execution stage that evaluates a filter expression and executes either the 'then' branch or 'else' branch based on the result.

Non-blocking control flow stage. The filter expression is evaluated once at the start. Only the selected branch (then or else) is executed - the other branch is never opened. Useful for conditional query execution that avoids evaluating unnecessary paths.

Test/utility stage that scans a pre-loaded vector of BSON documents. Can optionally extract top-level fields into separate slots.

Non-blocking streaming stage. Returns one BSON document at a time. Primarily used for testing and internal operations. Documents are stored in-memory. Unlikely to appear in production query plans.

The query planner retrieves a previously cached plan for this query shape. Monitors performance during a trial period and triggers replanning if the cached plan underperforms.

Non-blocking wrapper stage. Avoids re-planning overhead for repeated query shapes. Monitors plan performance during a trial period.

Executes a cached query plan from the plan cache. Monitors performance to detect if the cached plan should be replaced.

Non-blocking wrapper stage. Uses cached plan to avoid re-planning queries. Monitors plan performance during a trial period. Triggers replanning if the cached plan performs poorly compared to expectations. Reduces overhead by skipping query planning for repeated query shapes.

Constant filter variant where the predicate does not depend on input values. Evaluates the predicate once at the start. If false, immediately returns no results.

Non-blocking streaming stage. Optimized variant for predicates known before execution begins. The filter is evaluated once at the start rather than per document.

Validated index bounds during index scans. Removed in MongoDB 7.0 (SERVER-68102) - functionality merged into ixscan stage.

Non-blocking streaming stage. Ensured index scan stayed within specified bounds.

The query planner selects a scan of a clustered collection where data is physically stored in clustered index order. Eliminates the need for a separate fetch stage since documents are accessed directly.

Non-blocking streaming stage. More efficient than IXSCAN + FETCH for clustered collections since data is stored in index order. Supports bounded and unbounded scans over the clustered index.

Scans a clustered collection where data is physically stored in clustered index order. Used for collections with a clustered index on _id.

Non-blocking streaming stage. For clustered collections, data is stored in index order. Eliminates need for separate index lookup and fetch stages - data is accessed directly. More efficient than IXSCAN + FETCH combination for clustered collections. Clustered collections introduced in MongoDB 5.3 optimize _id-based access patterns. Supports bounded and unbounded scans over the clustered index.

The query planner selects a full collection scan, reading every document sequentially without using an index. Indicates no suitable index exists for the query predicates.

Non-blocking streaming stage. Can be slow for large collections. Generally indicates a missing index — consider adding an index if this appears in slow queries.

Scans all documents in the collection sequentially without using an index. Reads every document from the collection in natural order.

Non-blocking streaming stage. Can be slow for large collections. Generally indicates missing index - consider adding an index if this appears in slow queries.

Produces an infinite stream of ADVANCED results without any data. Used to drive execution when no physical data source is needed.

Non-blocking streaming stage with minimal overhead. Does not produce any values itself - just drives iteration. Typically combined with project stages to produce constant values or drive nested loops.

The query planner adds a count node to tally documents from its child stage, applying optional skip and limit. Sits at the root of count operation plans.

Non-blocking streaming stage. Does not buffer documents — just maintains a counter. Very lightweight.

Counts the number of documents returned by its child stage, applying optional skip and limit. Sits at the root of count operation plans.

Non-blocking streaming stage. Returns NEED_TIME until child hits EOF. Does not buffer documents - just maintains a counter. Very lightweight. Note: different from COUNT_SCAN which is an index access optimization.

The query planner selects an optimized index scan for count operations. Counts index entries directly without full key examination, using index bounds to count documents within a range.

Non-blocking streaming stage. Can skip key deserialization when only the count is needed. Generally faster than scanning documents when an appropriate index exists.

Optimized index scan for count() queries. Skips key examination when possible, just counting index entries instead of fully processing them.

Non-blocking streaming stage. Optimized for counting index entries. Can skip key deserialization when only the count is needed. Works with index bounds to count documents within a range. Generally faster than scanning documents when an appropriate index exists.

The query planner adds a delete node to remove documents matching the query criteria. Deletes documents and updates all affected indexes.

Non-blocking streaming stage. Deletes documents one at a time. Performance depends on index count and document size.

Deletes documents matching the query criteria. Removes documents from the collection and updates all affected indexes.

Non-blocking streaming stage. Deletes documents one at a time as they're received. Acquires write locks per document. Updates all indexes and writes to oplog. Performance depends on index count and document size. May yield during execution to allow other operations.

The query planner selects an optimized index scan for distinct operations. Uses key-skipping behavior to jump over duplicate index keys efficiently.

Non-blocking streaming stage. Much more efficient than full index scan + deduplication. Performance improvement proportional to the number of duplicates.

Optimized index scan for distinct() queries that skips duplicate values. Uses key-skipping behavior to jump over duplicate index keys efficiently.

Non-blocking streaming stage. Much more efficient than full index scan + deduplication. Skips over duplicate keys by seeking to next distinct value. Requires appropriate index on the distinct field. Performance improvement proportional to number of duplicates.

Early-exit filter variant that stops processing when the predicate evaluates to false. Unlike regular filter which skips non-matching rows, efilter terminates the scan entirely.

Non-blocking streaming stage. Optimized for predicates where the first false result means no more matches are possible (e.g., sorted data with range predicates). Returns EOF immediately when predicate fails, rather than continuing to scan.

The query planner produces an empty result set. Immediately returns EOF without producing any results. Used as a placeholder in query plans or to represent provably empty result sets.

Non-blocking marker stage. No actual work performed — immediately signals EOF. Minimal overhead.

Marker stage indicating end of result stream. Immediately returns EOF without producing any results.

Non-blocking marker stage. No actual work performed - immediately signals EOF. Used as placeholder in query plans or to represent empty result sets. Minimal overhead.

The query planner pushes a $lookup with an equality condition into the execution engine. Joins documents from a foreign collection based on matching field values.

Blocking on the inner (foreign) side — builds a hash table from the foreign collection before streaming the outer side. Can spill to disk when the hash table exceeds memory limits. Performance depends on the size of the foreign collection and selectivity of the join key.

The query planner fuses a $lookup immediately followed by $unwind on the joined field into a single plan node. Produces one output document per matched foreign document instead of creating an intermediate array.

Blocking on the inner (foreign) side. More efficient than separate EQ_LOOKUP + UNWIND because it avoids materializing intermediate arrays.

MongoDB 8.0+ optimized scan for clustered collections. Direct document lookup by _id on collections where data is physically stored in _id order.

Non-blocking streaming stage. Part of Express execution path. For clustered collections, directly looks up documents by _id. Produces at most one document per query. Tends to be faster than traditional CLUSTERED_IXSCAN for simple _id lookups.

MongoDB 8.0+ optimized delete operation. Streamlined write path for simple single-document deletes by _id.

Non-blocking write stage. Part of Express execution path. Streamlined path for simple _id-based deletes. Can optionally return the deleted document for findAndModify operations. Lower latency than standard delete path for qualifying operations.

MongoDB 8.0+ optimized index scan that bypasses regular query planning. Streamlined execution path for simple _id or single-field equality queries.

Non-blocking streaming stage. Part of Express execution path introduced in MongoDB 8.0. Bypasses query planning overhead for simple index lookups. For _id queries, produces at most one document. For user indexes, can produce multiple matches. Tends to be faster than traditional IXSCAN for simple equality queries.

MongoDB 8.0+ optimized update operation. Streamlined write path for simple single-document updates by _id.

Non-blocking write stage. Part of Express execution path. Streamlined path for simple _id-based updates. Supports both in-place updates and full document replacement. Handles shard key immutability checks for sharded clusters. Does not support upserts or positional updates (must be simple _id queries). Lower latency than standard update path for qualifying operations.

Extracts nested field paths from input slots in a single pass. Optimizes field access by computing multiple output paths from shared input slots.

Non-blocking streaming stage. Efficiently extracts multiple nested paths in one pass over the input, avoiding repeated document traversal.

Fetches full documents by record ID in SBE engine. Typically appears after an index scan when the query requires fields not covered by the index.

Non-blocking streaming stage. Performs random disk I/O to fetch documents. Can be a performance bottleneck when fetching many documents.

The query planner adds a fetch stage to retrieve full documents from the collection using RecordIds produced by a child index scan. May apply residual filter predicates after fetching.

Non-blocking streaming stage. Fetches one document per RecordId. Performance depends on document locality on disk and filter selectivity.

Retrieves full documents from the collection using RecordIds from an index scan.

Non-blocking streaming stage. Fetches one document per RecordId from child stage. Can apply filter expressions after fetching full document. Performance depends on document locality on disk and filter selectivity.

Standard filter stage that evaluates predicates on each input row. Passes through rows where the predicate evaluates to true.

Non-blocking streaming stage. Evaluates predicate expression for each row. Efficient for selective predicates. See also cfilter (constant predicates) and efilter (early-exit).

The query planner selects a 2d geospatial near query. Finds documents near a point using a 2d index and returns results sorted by distance.

Blocking stage — must fetch and sort all matching documents by distance. Implicitly includes document fetch and distance-based sort. Performance depends on search radius and document density.

Finds documents near a point using 2d geospatial index. Returns results sorted by distance from the query point.

Blocking stage - must fetch and sort all matching documents by distance. Uses 2d index for initial candidate selection, then computes exact distances. Implicitly includes document fetch and distance-based sort. Performance depends on search radius and document density.

The query planner selects a 2dsphere geospatial near query. Finds documents near a point on a sphere using spherical geometry calculations.

Blocking stage — must fetch and sort all matching documents by distance. Uses 2dsphere index with spherical geometry. More accurate than 2d for Earth-based coordinates (lat/long).

Finds documents near a point on a sphere using 2dsphere geospatial index. Returns results sorted by distance, supporting spherical geometry.

Blocking stage - must fetch and sort all matching documents by distance. Uses 2dsphere index with spherical geometry calculations. More accurate than 2d for Earth-based coordinates (lat/long). Implicitly includes document fetch and distance-based sort.

SBE engine's hash-based aggregation stage. Groups documents by specified keys and computes aggregate values using hash tables for efficient in-memory grouping.

Blocking stage that must consume all input before producing output. Uses hash tables for grouping, which tends to be faster than the classic engine equivalent. Can spill to disk when memory limit is exceeded (default 100MB, controlled by internalQuerySlotBasedExecutionHashAggApproxMemoryUseInBytesBeforeSpill).

The query planner pushes a $group aggregation into the execution engine. Groups documents by specified keys and computes aggregate values.

Blocking stage — must consume all input before producing output. Memory usage grows with the number of distinct grouping keys. Can spill to disk when memory limit is exceeded (default 100MB).

Traditional hash join implementation. Builds hash table from outer/build side, then probes with inner side. Equality join on specified condition slots.

Blocking on outer (build) side - must fully consume outer input to build hash table. Then streams inner (probe) side through the join. Memory usage proportional to outer side size. Efficient for equality joins.

SBE engine's hash join implementation for vector search embedding lookups. Builds a hash table from the inner side and probes it with embedding vectors.

Blocking on the build side — must materialize the hash table before probing. Memory usage depends on the number of embeddings in the inner collection.

Performs a hash join for vector search embedding lookups. Builds a hash table from one side of the join and probes it with embedding vectors from the other side.

Blocking on the build side — must materialize the hash table before probing. Used in vector search query plans for joining embedding results.

Multi-key hash lookup combining left join and unwind for $lookup operations. Builds hash table from inner side, streams outer side through.

Blocking on inner (right) side - builds hash table from all inner rows before streaming begins. Then streams outer (left) side while probing the hash table for matches. Each outer row is paired with an array of matched inner rows. Can spill hash table to disk when memory limit is exceeded.

Hash lookup combined with unwind optimization for $lookup operations. Like hash_lookup but unwinds results instead of creating arrays.

Blocking on inner side - builds hash table from all inner rows. Combines hash lookup and unwind into a single stage, avoiding the overhead of creating intermediate arrays then immediately unwinding them.

Abbreviated debug string representation of hash_join. Same as hash_join - builds hash table from outer side, probes with inner side.

Alias for hash_join in explain output. See hash_join for performance details.

The query planner selects an optimized fast path for single-document lookup by _id. Bypasses normal query planning for _id equality queries.

Non-blocking streaming stage. Returns at most one document. Direct index lookup without bounds checking. Only used when query collation matches collection default collation.

Optimized fast path for single-document lookup by _id. Bypasses normal query planning for _id equality queries.

Non-blocking streaming stage. Optimized for _id lookups. Returns at most one document. Direct index lookup without bounds checking. Only used when query collation matches collection default collation.

Probes an index to retrieve candidate documents for vector search. Used as the inner side of embedding join nodes to efficiently locate documents by indexed embedding vectors.

Non-blocking streaming stage. Efficiency depends on index selectivity and the number of probes required by the parent join node.

SBE engine's indexed nested loop join for vector search embedding lookups. Uses an index on the inner side to efficiently locate matching embeddings for each outer document.

More efficient than a plain nested loop join because index probes replace full scans of the inner side. Preferred when a suitable index exists on the embedding field.

Performs an indexed nested loop join for vector search embedding lookups. Uses an index on the inner side to efficiently find matching embeddings for each outer document.

More efficient than a plain nested loop join because it uses an index to probe the inner side. Used in vector search query plans when a suitable index is available on the embedding field.

Scans an index in the slot-based execution engine. Projects values from the index key and returns RecordIds for fetching documents.

Non-blocking streaming stage. Scans index entries in order. Supports both forward and backward scans. Generally faster than collection scans for selective queries. Often followed by a fetch stage if non-indexed fields are needed.

The query planner selects an index scan to find matching documents. Traverses the chosen index from startKey to endKey, applying any index-level filters.

Non-blocking streaming stage. Efficiency depends on index selectivity and the number of keys examined. Deduplicates on RecordId for multikey indexes.

Scans index keys to find matching documents. Traverses index from startKey to endKey, optionally applying filters.

Non-blocking streaming stage. Scans index in order (forward or backward). Deduplicates on RecordId for multikey indexes. Can apply filter expressions over index fields during scan. Efficient when index selectivity is high.

Generic index scan supporting complex index bounds. Similar to ixscan but handles more complex bound specifications and multi-interval scans.

Non-blocking streaming stage. Returns documents from index in index order. Supports complex bounds and multi-interval scans. Can extract index key values into separate slots for covered queries.

Index scan that performs point lookups (seeks) for specific keys rather than range scans. Optimized for equality predicates.

Non-blocking streaming stage. More efficient than ixscan for point lookups. Seeks directly to specific index keys without scanning ranges. Ideal for equality predicates and IN queries with specific values.

Limits the number of results returned from the input stream. Alias or variant of limit_skip stage.

Non-blocking streaming stage. Returns up to N documents then stops. Very efficient - no buffering required. Can stop pipeline execution early.

The query planner adds a limit node to cap the number of documents returned. Stops execution early once the specified number of documents is reached.

Non-blocking streaming stage. Very efficient — no buffering required. Can stop pipeline execution early once limit is reached.

Limits the number of documents returned from the input stream. Stops execution after returning the specified number of documents.

Non-blocking streaming stage. Very efficient - no buffering required. Can stop pipeline execution early once limit is reached.

Limits the number of results or skips results from child stage. Skip and limit values are evaluated when the plan is opened.

Non-blocking streaming stage. Very efficient - just counts documents and stops/skips as needed. If both skip and limit are present, skips first then applies limit.

The query planner pushes a $match filter into the execution engine. Evaluates a predicate on each document and passes through those that match.

Non-blocking streaming stage. Evaluates predicate for each document. Efficient for selective predicates that eliminate most input early.

Merge join for sorted inputs. Equi-join that requires both sides sorted by join keys. Buffers outer rows to support full cross product for matching keys.

Non-blocking but buffers groups of matching outer rows temporarily. O(N + M) complexity when inputs are sorted, making it efficient for pre-sorted data. Works well when an index provides the required sort order for both sides.

Abbreviated debug string representation of merge_join. Same as merge_join - joins sorted inputs efficiently.

Alias for merge_join in explain output. See merge_join for performance details.

Constructs BSON objects from input slots. Similar to mkobj but produces BSON-encoded objects instead of SBE value objects.

Non-blocking streaming stage. Constructs one BSON object per input row. Produces BSON-encoded output, which may be required for returning results to clients. Slightly more overhead than mkobj due to BSON serialization.

Constructs SBE objects from input slots. Can build new objects from scratch or modify existing objects by adding, dropping, or keeping fields.

Non-blocking streaming stage. Constructs one object per input row. Can drop specified fields, keep only specified fields, or add new computed fields. See also mkbson for BSON object construction.

The query planner coordinates multiple record store cursors for queries that need to scan the same collection with different strategies.

Non-blocking streaming stage. Coordinates multiple cursors over the same collection. Memory overhead proportional to number of active cursors.

Manages multiple record store cursors for queries that need to scan the same collection multiple times or with different strategies.

Non-blocking streaming stage. Coordinates multiple cursors over the same collection. Used for complex queries requiring multiple scan strategies. Memory overhead proportional to number of active cursors.

The query planner evaluates multiple candidate plans in parallel during a trial period. Selects the best performing plan based on trial run metrics and caches it for future queries.

Non-blocking wrapper stage. Runs candidate plans concurrently during trial. Adds overhead to first execution but improves subsequent query performance through plan caching.

Executes multiple candidate query plans in parallel during a trial period. Selects the best performing plan based on trial run metrics.

Non-blocking wrapper stage. Runs candidate plans concurrently during trial. Trial period limited by work units or document count. Winning plan is cached for future queries. Ensures optimal plan selection when multiple viable plans exist. Adds overhead to first execution but improves subsequent query performance.

SBE engine's nested loop join implementation for vector search embedding lookups. For each outer document, iterates the inner side to find matching embeddings.

Non-blocking but cost grows with the product of outer and inner side sizes. Used when a hash join is not suitable for the embedding lookup.

Performs a nested loop join for vector search embedding lookups. For each outer document, scans the inner side to find matching embeddings.

Non-blocking but potentially expensive — iterates the inner side for each outer document. Used in vector search query plans when a hash join is not suitable.

Traditional nested loop join. For each outer row, re-opens and scans the entire inner side. Supports optional join predicate, otherwise produces Cartesian product.

Non-blocking streaming stage but can be expensive for large datasets. Re-scans inner side for every outer row, resulting in O(N*M) complexity. Hash join or merge join are typically more efficient for large datasets. Useful for correlated subqueries where the inner side depends on outer values.

The query planner combines results from multiple child stages representing OR conditions. Deduplicates results based on RecordId.

Non-blocking streaming stage. Buffers RecordIds to deduplicate results. Memory usage proportional to result set size.

Combines results from multiple child stages representing OR conditions. Deduplicates results based on RecordId.

Non-blocking streaming stage. Buffers RecordIds to deduplicate results. Memory usage proportional to result set size. Evaluates children and merges results, removing duplicates.

Projects and computes new fields in SBE engine. Evaluates expressions to create output slots from input slots.

Non-blocking streaming stage. Evaluates expressions to compute projected fields. Performance depends on the complexity of projection expressions.

The query planner selects a covered projection that returns fields directly from index data. No document fetch is required — the query is entirely covered by the index.

Non-blocking streaming stage. Avoids document fetch entirely. All projected fields come from index data. Requires an index containing all projected fields and query predicates.

Projection that returns fields directly from index data. No document fetch required - query is entirely covered by the index.

Non-blocking streaming stage. Avoids document fetch entirely. All projected fields come from index data. Requires index containing all projected fields and query predicates.

The query planner adds a default projection to compute projected fields from full documents. Handles complex projections including computed fields and expressions.

Non-blocking streaming stage. Most general projection implementation. Requires full document fetch — cannot use index-only data.

Standard field projection that computes projected fields from full documents. Handles complex projections including computed fields and expressions.

Non-blocking streaming stage. Processes one document at a time. Most general projection implementation supporting all projection types. Requires full document fetch - cannot use index-only data. Performance depends on projection complexity and document size.

The query planner selects an optimized projection for simple field inclusion/exclusion without expressions. Faster than default projection when only including or excluding fields.

Non-blocking streaming stage. More efficient than PROJECTION_DEFAULT. Faster field traversal and copying. Still requires full document fetch.

Optimized projection for simple field inclusion/exclusion without expressions. Faster than default projection when only including or excluding fields.

Non-blocking streaming stage. More efficient than PROJECTION_DEFAULT. Used when projection is simple inclusion/exclusion without computed fields. Faster field traversal and copying. Still requires full document fetch.

Retrieves documents from a collection in random order using the storage engine's random cursor. Used for efficient random sampling operations.

Non-blocking streaming stage. Uses storage engine's random cursor for efficient sampling without scanning the entire collection.

The query planner selects a fast count using collection metadata without scanning documents or indexes. Only possible when the query has no predicates.

Non-blocking stage with O(1) complexity. Reads count directly from collection metadata.

Returns document count using collection metadata without scanning. Avoids scanning documents or indexes entirely.

Non-blocking stage with O(1) complexity. Reads count directly from collection metadata. Only usable when query has no predicates and collection is not capped.

SBE engine's implementation of document root replacement. Evaluates an expression for each input document and replaces the root with the result.

Non-blocking streaming stage. Transforms each document individually by evaluating the replacement expression in the SBE VM.

The query planner pushes a $replaceRoot or $replaceWith operation into the execution engine. Replaces each document with a specified embedded document or expression result.

Non-blocking streaming stage. Transforms each document individually.

The query planner adds a return key node to return only index keys without fetching full documents. Used with the returnKey option to inspect index key values.

Non-blocking streaming stage. Very efficient — no document fetch required. Returns raw index key for each result.

Returns only index keys without fetching full documents. Used with returnKey option to inspect index key values.

Non-blocking streaming stage. Very efficient - no document fetch required. Returns raw index key for each result. Primarily used for debugging and index analysis. Minimal overhead compared to full document retrieval.

The query planner selects a time-series bucket sampling strategy. Randomly samples measurements from time-series buckets, selecting one random measurement from each sampled bucket.

Non-blocking streaming stage. More efficient than unpacking all measurements then sampling, as it samples at the bucket level first.

Randomly samples measurements from time-series buckets. Selects one random measurement from each sampled bucket.

Non-blocking streaming stage. Each bucket iteration produces one random measurement. Deduplicates to avoid returning the same measurement twice. More efficient than unpacking all measurements then sampling, as it samples at the bucket level first. Introduced in MongoDB 5.0 for optimized $sample on time-series collections.

Retrieves documents from a collection using the storage API. Can extract top-level fields from documents and supports forward/backward scanning.

Non-blocking streaming stage. Reads documents sequentially from the collection. Performance depends on collection size and whether an index could be used instead. Generally indicates missing index if this appears in queries with selective predicates.

The query planner delegates a $search query to the mongot (Atlas Search) service. Retrieves search results from the remote service and outputs documents with search metadata.

Non-blocking streaming stage. Performance depends on network latency to the mongot service and the complexity of the search query. Supports stored source optimization to avoid additional collection lookups.

Maintains a mongot cursor for $search queries. Retrieves search results from the remote mongot service and outputs documents with metadata.

Non-blocking streaming stage. Fetches one response from mongot per getNext() call. Supports both stored source (full documents) and non-stored source (IDs only). Can extract specific fields and metadata into separate slots. Performance depends on network latency to mongot service. Supports sort spec, limit, and collation for server-side optimization.

Seeks to a specific document by RecordId in SBE engine. Typically appears after an index scan to fetch the full document using the RecordId returned by the index. This is a variant of the scan stage that performs a point lookup rather than a sequential scan.

Non-blocking streaming stage. Performs a single seek operation to fetch a document by its RecordId. More efficient than a full collection scan when fetching specific documents. Index key consistency checks may be performed to detect snapshot inconsistencies after yields.

Represents the execution context of a specific shard in a sharded cluster query. Contains the shard's total execution time (including optimization overhead) and execution success status. This is a synthetic node inserted to preserve per-shard identity and timing that would otherwise be lost.

The shard execution time includes query optimization overhead on the shard, which may be significantly higher than the child stage execution time. A large gap between shard execution time and child execution time indicates optimization cost.

Merges unsorted results from multiple shards. Appears in sharded cluster explains when a query must be executed on multiple shards and the results don't require sorted merging.

Scatter-gather operation across shards. Results are returned as they arrive from each shard without ordering guarantees. More efficient than SHARD_MERGE_SORT when ordering is not required.

Merges sorted results from multiple shards while preserving sort order. Appears in sharded cluster explains when a query with a sort is executed on multiple shards.

Performs a streaming merge sort of pre-sorted results from each shard. Each shard sorts its own results, and mongos merges them maintaining the global sort order. More expensive than SHARD_MERGE due to the coordination required to maintain ordering.

Distributes write operations across shards. Appears in sharded cluster explains for insert, update, and delete operations that affect documents on multiple shards.

Write operations are distributed to the appropriate shards based on the shard key. Updates and deletes without the shard key in the filter require a scatter-gather to all shards.

The query planner adds a shard ownership filter to ensure query correctness in sharded clusters. Filters out documents not owned by the current shard based on shard key.

Non-blocking streaming stage. Very lightweight shard ownership check. Essential during chunk migrations to filter orphaned documents.

Filters out documents not owned by the current shard based on shard key. Critical for sharded clusters to ensure query correctness during migrations.

Non-blocking streaming stage. Evaluates shard ownership for each document. Very lightweight check using shard key metadata. Essential during chunk migrations to filter orphaned documents. Minimal overhead in stable clusters, critical for correctness during migrations.

Indicates the query was routed to a single shard. Appears in sharded cluster explains when the query's filter includes the shard key prefix, allowing mongos to target a specific shard.

Most efficient sharded query pattern. The query only needs to contact one shard, avoiding the overhead of scatter-gather operations across multiple shards.

The query planner adds a skip node to discard the first N documents from the input stream before passing results through.

Non-blocking streaming stage. No buffering — just counts and discards first N documents. Still requires reading the skipped documents from storage.

Skips a specified number of documents from the input stream before passing results through to the parent stage.

Non-blocking streaming stage. No buffering - just counts and discards first N documents. Efficient but still requires reading the skipped documents from storage.

Merges outputs from multiple sorted child stages into a single sorted output stream. Each child must produce results in sorted order.

Non-blocking streaming stage. Selects the next value from whichever child has the smallest key. Assumes all inputs are already sorted - does not sort inputs itself. Commonly used when merging results from multiple index scans.

Sorts incoming data by specified order-by keys. Materializes rows in memory and can spill to disk if memory limit is exceeded.

Blocking stage - must consume all input before producing output. Materializes rows for sorting. Can be expensive for large result sets. Spills to disk when memory limit exceeded if allowDiskUse is true. Can be optimized to top-k sort if a limit is present.

The query planner adds an in-memory sort when no index supports the requested sort order. Both STAGE_SORT_DEFAULT and STAGE_SORT_SIMPLE appear as SORT in explain output.

Blocking stage — must consume all input before producing output. Can spill to disk when memory limit exceeded (default 100MB). Consider adding an index to avoid in-memory sorting.

Sorts documents in memory when no index supports the sort order. Loads all input documents, sorts them, then returns sorted results.

Blocking stage - must consume all input before producing output. Can spill to disk when memory limit exceeded (default 100MB, controlled by internalQueryMaxBlockingSortMemoryUsageBytes). Consider adding an index to avoid in-memory sorting.

Default sorting implementation for documents when no index supports the sort order. Handles complex sort patterns and all BSON data types.

Blocking stage - must consume all input before producing output. Can spill to disk when memory limit exceeded (default 100MB). Handles complex sort patterns including collations, arrays, and all BSON types. When combined with LIMIT, can use a more efficient top-K algorithm that only tracks the top N documents rather than sorting everything.

The query planner adds a sort key extraction stage to prepare documents for downstream sorting. Computes comparable sort keys including dotted paths, arrays, and collation rules.

Non-blocking streaming stage. Extracts sort keys from documents as they flow through. Handles complex sort key extraction including collation rules.

Extracts and generates sort keys from documents for sorting operations. Prepares documents for downstream SORT stages by computing comparable keys.

Non-blocking streaming stage. Extracts sort keys from documents as they flow through. Handles complex sort key extraction including dotted paths, arrays, and missing fields. Applies collation rules when extracting string sort keys.

The query planner merges multiple pre-sorted input streams into a single sorted output stream. Common when combining results from multiple index scans that share a sort order.

Non-blocking streaming stage. Uses a priority queue to select the next document from sorted inputs. No sorting or buffering required — just merging.

Merges multiple pre-sorted input streams into a single sorted output stream. Assumes all inputs are already sorted in the same order.

Non-blocking streaming stage. Efficiently merges pre-sorted streams. Uses priority queue to select next document from sorted inputs. No sorting or buffering required - just merging. Common when combining results from multiple index scans.

Optimized sorting implementation for simple sort patterns. Used when sort can be performed more efficiently than default sort.

Blocking stage - must consume all input before producing output. Can spill to disk when memory limit exceeded (default 100MB). Optimized for simple sort patterns without complex collations. Query planner selects this variant when the sort pattern qualifies.

The query planner adds a spool to eagerly buffer all input for later reuse. Caches RecordIds in memory or on disk for operations requiring multiple passes over the same data.

Blocking stage — must consume all input before producing output. Can spill to disk. Only caches references (not full documents) to reduce memory and disk usage.

Eagerly buffers all input from child stage for later reuse. Caches RecordIds in memory or on disk for multiple-pass operations.

Blocking stage - must consume all input before producing output. Can spill to disk. Reads all input and caches document references (RecordIds) for reuse. Only caches references (not full documents) to reduce memory and disk usage. Used for operations requiring multiple passes over the same data, such as self-joins or certain window functions.

The query planner decomposes a rooted $or query into separate subplans, one per $or branch. Each subplan is planned and cached independently for better performance.

Non-blocking wrapper stage. Plans each $or branch independently. Enables per-branch plan caching and can leverage different indexes for different branches.

Executes rooted $or queries as separate subplans, one per $or branch. Each subplan is planned and cached independently for better performance.

Non-blocking wrapper stage. Plans each $or branch independently. Enables per-branch plan caching for rooted $or queries. More efficient than single-plan approach for complex $or queries. Can leverage different indexes for different branches.

The query planner adds a text match filter to evaluate text search criteria and compute relevance scores for matching documents.

Non-blocking streaming stage. Evaluates text search predicates and computes relevance scores. Performance depends on text complexity and number of terms.

Filters documents based on text search criteria. Evaluates text search expressions and scores results by relevance.

Non-blocking streaming stage. Evaluates text search predicates on documents. Works with text index scan results. Computes text relevance scores. Performance depends on text complexity and number of terms.

The query planner combines results from multiple text search terms using OR logic. Merges, deduplicates, and aggregates text scores across terms.

Non-blocking streaming stage. Merges results from multiple text search terms. Deduplicates documents matching multiple terms.

Combines results from multiple text search terms using OR logic. Merges and deduplicates text search results from different terms.

Non-blocking streaming stage. Merges results from multiple text search terms. Deduplicates documents matching multiple terms. Aggregates text scores across terms. Used internally for text search queries.

The query planner selects a time-series modification strategy for update or delete operations on time-series collections. Modifies measurements within bucket documents.

Non-blocking write stage for time-series collections. Unpacks buckets, applies modifications to matching measurements, then repacks. More complex than regular document updates due to bucket-based storage.

Handles update and delete operations on time-series collections. Modifies bucket documents by updating or removing measurements within buckets.

Non-blocking write stage for time-series collections. Supports both update and delete operations on measurements within buckets. Unpacks buckets, applies modifications to matching measurements, then repacks buckets. Handles bucket splitting when modifications cause bucket size to exceed limits. More complex than regular document updates due to bucket-based storage model. Introduced in MongoDB 5.0 when time-series updates/deletes were added.

The query planner runs a trial period to evaluate candidate plan performance. Collects metrics to help select the optimal plan before full execution.

Non-blocking wrapper stage. Runs during multi-planning trial period. Limited execution — stops after trial work units consumed.

Executes candidate query plans during a trial period to measure performance. Collects metrics to help select the optimal plan.

Non-blocking wrapper stage. Runs during multi-planning trial period. Collects performance metrics for plan selection. Limited execution - stops after trial work units consumed. Helps identify best plan before full query execution.

Converts time series bucket BSON documents to CellBlock columnar format. Extracts requested paths into separate cell blocks for efficient processing.

Non-blocking streaming stage. Processes one time series bucket at a time. Produces columnar data structures for efficient processing of time series data. Enables block-based processing optimizations for time series queries.

Combines values from multiple input streams into one stream. Executes each branch in turn until EOF, remapping slots to common output.

Non-blocking streaming stage. Executes branches sequentially, not in parallel. Exhausts each branch completely before moving to the next. Results from all branches are combined into a single output stream.

Deduplicates rows by key using a hash set. Unlike hash aggregation, this stage is non-blocking and preserves input order.

Non-blocking streaming stage. Maintains hash set of seen keys in memory. Preserves input order - first occurrence of each key is returned. Memory usage grows with the number of unique keys encountered.

Specialized deduplication stage for single integral keys using roaring bitmaps. More memory-efficient than unique for integer keys.

Non-blocking streaming stage. Uses roaring bitmap for memory-efficient deduplication. Only supports single integral key (not composite keys). More memory-efficient than a hash set when deduplicating integer keys. Preserves input order.

Unpacks documents from a time-series bucket during a $sample operation. Used when sampling from a time-series collection — randomly selects measurements from within time-series buckets.

Specialized stage for $sample on time-series collections. Extracts individual measurements from randomly selected bucket documents.

The query planner adds an unpack stage to materialize individual measurements from compressed time-series bucket documents. Present in every time-series query plan.

Non-blocking streaming stage. Each bucket can contain hundreds or thousands of measurements. Iterates through all measurements within each bucket before moving to the next.

Unpacks compressed time-series bucket documents into individual measurements. Materializes measurements one at a time from buckets fetched by child stage.

Non-blocking streaming stage. Materializes individual measurements from time-series buckets. Each bucket can contain hundreds or thousands of measurements depending on time window. Iterates through all measurements within each bucket before moving to the next. Present in every time-series query execution plan.

Returns array elements one-by-one with associated array indices. Reads array from input slot, outputs elements and indices to separate slots.

Non-blocking streaming stage. Produces one row per array element. Can optionally preserve null and empty arrays with preserveNullAndEmptyArrays flag. Generally efficient unless arrays are very large.

The query planner pushes an $unwind operation into the execution engine. Deconstructs an array field, producing one output document per array element.

Non-blocking streaming stage. Produces one row per array element. Output cardinality depends on array sizes — can significantly multiply document count for large arrays.

The query planner adds an update node to apply modifications to documents matching the query criteria. Handles update operators and full document replacements.

Non-blocking streaming stage. Updates documents one at a time. Performance depends on update complexity, index count, and document size.

Updates documents matching the query criteria. Applies update operators or replacement documents to matched documents.

Non-blocking streaming stage. Updates documents one at a time as they're received. Acquires write locks per document. Can trigger index updates and oplog writes. Performance depends on update complexity, index count, and document size. May yield during execution to allow other operations.

Simulates a collection scan without depending on underlying storage. Used for testing and providing in-memory data to query execution.

Non-blocking streaming stage. Iterates over in-memory array of documents. Does not touch storage layer - purely in-memory operation. Primarily used for testing query execution without real collections. Also used internally for certain optimizations and special query patterns. Very fast since no disk I/O involved.

Test/utility stage that returns values from a pre-loaded array one at a time. Mimics resource management behavior of real scan stages for testing.

Non-blocking streaming stage. Returns one value at a time from an in-memory array. Primarily used for internal testing purposes. Unlikely to appear in production query plans.

Performs partitioned sliding window aggregations for $setWindowFields. Maintains window frames within partitions, evaluating window functions over sliding ranges.

Semi-blocking stage - buffers documents within each partition. Can spill window buffer to disk when memory threshold is exceeded (controlled by internalDocumentSourceSetWindowFieldsMaxMemoryBytes). Output streams as each partition completes. Window frame bounds (e.g., 'unbounded' vs 'N preceding') affect how many documents must be buffered at once.

The query planner pushes a $setWindowFields operation into the execution engine. Computes window functions over partitioned, ordered sets of documents.

Semi-blocking — buffers documents within each partition. Output streams as each partition completes. Can spill to disk when the window buffer exceeds memory limits. Window frame bounds affect how many documents must be buffered at once.