What does $expr allow inside a $match stage that ordinary query operators cannot do?

## Two languages in one product MongoDB has two distinct expression languages. The **query language** is what you pass to `find()` and to `$match`: a document of field-to-predicate pairs, where `{ status: "open", qty: { $gte: 10 } }` means "status equals open AND qty is at least 10". The **aggregation expression language** is what you write inside `$project`, `$group` and friends: prefix-form operators over argument arrays, such as `{ $gte: ["$qty", 10] }`, where any argument may be a field path, a literal, or another expression. The query language is deliberately restricted, which is what makes it index-friendly, but the restriction bites: the right-hand side of a query predicate is always a value, never a reference to another field. `$expr` is the bridge that lets you drop an aggregation expression into a query context. ## The canonical use: comparing two fields "Find every project where spend exceeded budget" has no query-language spelling. Written the natural way, `{ spent: { $gt: "$budget" } }`, MongoDB compares `spent` to the eight-character string `"$budget"` — a comparison that matches nothing useful and raises no error. The correct form is: ```javascript db.projects.find({ $expr: { $gt: ["$spent", "$budget"] } }) ``` The same document works as a pipeline stage: `{ $match: { $expr: { $gt: ["$spent", "$budget"] } } }`. ## Computing inside the predicate Because the whole expression language is available, you can filter on things you would otherwise have to compute in an earlier `$set` stage: - `{ $expr: { $gt: [{ $size: "$items" }, 3] } }` — more than three line items. (The query-language `$size` operator only tests an exact length, so this is a genuine capability gain.) - `{ $expr: { $eq: [{ $dateTrunc: { date: "$createdAt", unit: "day" } }, ISODate("2024-05-01")] } }` — created on a particular day, without storing a separate date field. - `{ $expr: { $gt: ["$revenue", { $multiply: ["$cost", 1.2] }] } }` — margin above twenty percent. It also appears in schema-validation documents, where `$jsonSchema` cannot express a relationship between two fields but `$expr` can — for example requiring that `endDate` be later than `startDate`. ## Indexes and cost This is where candidates separate themselves. `$expr` is not automatically slow, but it is not automatically fast either: - A comparison **between two fields of the same document** can never be served by an index, because no single index key encodes the relationship. Every candidate document must be fetched and evaluated. If the collection is large, pair the `$expr` with an ordinary indexed predicate that narrows the set first: `{ $match: { status: "open", $expr: { $gt: ["$spent", "$budget"] } } }` lets the index on `status` do the narrowing. - `$expr` **does not support multikey indexes**, so a predicate over an array field will not get index help from one. The honest summary for an interview: treat `$expr` as an expressive filter that usually runs as a scan over whatever the rest of the predicate lets through, and verify with `explain()` rather than assuming. ## Array semantics differ, and this trips people The query language traverses arrays implicitly: `{ tags: "x" }` matches a document whose `tags` array *contains* `"x"`. Aggregation expressions do not. `{ $expr: { $eq: ["$tags", "x"] } }` compares the entire array value to the string and matches nothing. The aggregation-side equivalent is `{ $expr: { $in: ["x", "$tags"] } }` — note the argument order, value first, array second, the reverse of the query operator `$in`. Similarly, `{ "items.sku": "A1" }` in query language reaches into an array of sub-documents, while an expression path `"$items.sku"` evaluates to an *array of skus*. This asymmetry is the single most common `$expr` bug: a filter that silently matches nothing after someone converted a working query predicate into expression form. ## When not to use it If a plain query predicate expresses what you need, use it — it is more index-friendly and easier to read. `$expr` earns its place when the predicate genuinely relates two parts of the same document or requires computation. An alternative, when the computed value is needed more than once, is to compute it in a `$set` stage and match on the result in the next stage; in a pipeline that is often clearer, though it does not help the index situation either. If a field comparison drives a hot query path, the durable fix is usually to **store the derived value** — a boolean `overBudget` maintained on write — and index that instead.