In MongoDB, what does the find filter { tags: "red" } match when tags holds an array?

## A filter is a document Every `find()` call takes a filter document. Each key names a field (possibly a dotted path) and each value is either a literal or an operator expression. A literal is implicit equality: `{ tags: "red" }` and `{ tags: { $eq: "red" } }` are the same query. The explicit `$eq` form exists so you can combine equality with other operators on the same field, for example `{ tags: { $eq: "red", $ne: "blue" } }`. ## Equality against an array field MongoDB has no separate "contains" operator for the common case, because equality already covers it. When the engine evaluates an equality predicate on a field whose stored value is an array, it succeeds if **either** the whole array equals the operand **or** any single element equals it. That descent goes one level only. Given these documents: ``` { _id: 1, tags: "red" } { _id: 2, tags: ["red", "blue"] } { _id: 3, tags: ["blue", "green"] } { _id: 4, tags: [["red"], "blue"] } ``` `db.items.find({ tags: "red" })` returns documents 1 and 2. Document 3 has no matching element. Document 4 does not match either: its first element is the array `["red"]`, not the string `"red"`, and the engine does not recurse into nested arrays for this predicate. The practical consequence is that the same filter serves a single-valued field and a multi-valued one. That is convenient, and it is also why a field that silently changed from a scalar to an array in some documents can go unnoticed for a long time — reads keep working. ## Whole-array equality Put an array on the right-hand side and the semantics flip toward exactness. `{ tags: ["red", "blue"] }` matches a document whose `tags` is an array with exactly two elements, `"red"` then `"blue"`. `["blue", "red"]` does not match, and neither does `["red", "blue", "green"]`. Because element-level matching still applies, it *also* matches a document whose `tags` array contains `["red", "blue"]` as one of its elements — the nested-array case that surprises people. Order sensitivity is the important half: whole-array equality is almost never what an application wants when the array models a set of labels. ## Order-independent containment: $all `{ tags: { $all: ["red", "blue"] } }` matches any document whose `tags` array contains both values, in any order, with any number of other elements. It is equivalent to `{ $and: [ { tags: "red" }, { tags: "blue" } ] }`. Contrast `$in`, which is a logical OR over the listed values: `{ tags: { $in: ["red", "blue"] } }` matches a document whose array contains *either* value. The mnemonic is `$in` = any of, `$all` = all of, bare array = exactly this array in this order. ## Length: $size `{ tags: { $size: 3 } }` matches documents whose `tags` array has exactly three elements. `$size` takes a literal non-negative integer; you cannot write `{ $size: { $gt: 3 } }`, and there is no range form. Two standard workarounds exist. To test "at least N elements", use the fact that array positions are addressable by dotted path: `{ "tags.2": { $exists: true } }` is true only when a third element exists. For anything richer — sorting by length, filtering by a computed length — maintain a separate counter field that your writes keep in step, which also makes the predicate indexable. ## Where this bites The most common bug is assuming the filter tells you the shape of the data. `{ tags: "red" }` is happy either way, so code that later does `doc.tags.toUpperCase()` breaks on the array documents. Validate the shape at write time rather than inferring it from a successful read. The second is reaching for whole-array equality when you meant containment, then discovering that the query works in tests (where the fixture happens to be written in the same order) and fails in production. The third is putting two conditions on one array field and expecting them to hold for the same element. `{ scores: { $gte: 80, $lt: 90 } }` matches an array like `[95, 20]` because one element satisfies each condition independently; requiring one element to satisfy both is what `$elemMatch` is for. ## Indexing note An index on an array field is a multikey index: it stores one index entry per element, which is exactly why element-level equality can be served from the index. That mechanism is what makes `{ tags: "red" }` cheap on a large collection.