What does $unwind do to a document whose array field is empty or missing?

## What the stage does `$unwind` is the pipeline's array-flattening stage. For each input document it looks at the field named by `path` and, if that field holds an array, emits one output document per element. Every other field is copied verbatim; the array field itself is replaced by the single element. A document with `tags: ["x", "y"]` becomes two documents, one with `tags: "x"` and one with `tags: "y"`. This is the standard preparation step for grouping *by* array elements: you cannot ask "how many documents carry each tag" with `$group` alone, because the grouping key would be the whole array. Unwind first, then group on the now-scalar field. ## The empty, missing and null cases The short form has an important asymmetry. If the path resolves to an **empty array**, is **missing** from the document, or is **null**, there are zero elements to emit — and `$unwind` emits nothing, so the document disappears from the pipeline. Nothing warns you. A pipeline that reads `{ $match: {...} }, { $unwind: "$items" }, { $group: {...} }` quietly excludes every order with no items, and the totals downstream are wrong in a way that looks plausible. The object form is the fix: ```javascript { $unwind: { path: "$items", preserveNullAndEmptyArrays: true } } ``` With that option the document passes through once instead of being dropped, with no unwound element in that field. Reach for it whenever you are unwinding an optional array and the parent document must survive — for example a "customers and their orders" report where customers with no orders still need a row. ## Non-array values Since MongoDB 3.2, a path that holds a scalar — a string, a number, a sub-document — is treated as a one-element array: the document is emitted once, unchanged. This means `$unwind` is safe over a field whose type is inconsistent across documents, a common situation in a schema-flexible collection where some documents stored `tag: "x"` and others `tags: ["x", "y"]`. Earlier behaviour raised an error, which is worth knowing only because old answers still circulate. ## includeArrayIndex The object form takes `includeArrayIndex: "<newField>"`, which adds a field holding the zero-based position of the element within its original array. That is how you preserve ordering information that unwinding otherwise throws away — useful when you must later re-sort elements into their document order, or when you want "the first line item" identified positionally rather than by value. Combined with `preserveNullAndEmptyArrays`, documents that had nothing to unwind get `null` in that index field. ## Fan-out is the cost `$unwind` multiplies documents. A collection of 1 million orders averaging 8 line items produces 8 million documents in the stream, each carrying a full copy of the order's non-array fields. Everything downstream — sorts, groups, further stages — works on that inflated stream. Two habits keep it under control: - **Filter before you unwind.** Put the selective `$match` on the parent document first, so you never expand documents you are about to discard. - **Project away what you do not need before unwinding**, so the copies are small. If the order has a large `notes` field and your report only needs `items.sku`, dropping `notes` first cuts the bytes copied per element. You can also filter *after* the unwind on the element itself — `{ $unwind: "$items" }, { $match: { "items.sku": "A1" } }` — but note the semantics are different from matching before: the pre-unwind form `{ "items.sku": "A1" }` keeps whole documents that contain such an element, while the post-unwind form keeps only the matching elements themselves. Interviewers like this distinction because it is exactly the mistake that produces wrong per-element aggregates. ## Undoing an unwind A pipeline that unwinds, filters or transforms elements, and then needs the parent shape back rebuilds it with `$group`: group on `"$_id"`, `$push` the transformed elements into an array, and `$first` any parent fields you need to keep. The result is the original document with a filtered array. It is a well-worn idiom, and it is also a reminder that unwinding to filter array elements is not free — for simple cases `$filter` inside `$project`/`$set` does the same work without expanding the stream at all. ## Quick mental model Think of `$unwind` as a stream-level cross product between the document and its array. Zero elements means zero rows out — the same reason an inner join drops the parent row when the child table has nothing. `preserveNullAndEmptyArrays` is the outer-join switch.