When is a MongoDB wildcard index the right choice over indexes on named fields?

## The problem it solves Ordinary indexes require you to name the field. That breaks down when field names come from data rather than from a schema: a product catalog where every category contributes different attributes, a multi-tenant collection where each tenant defines its own custom fields, an event store whose payload keys vary per event type. You cannot enumerate the fields, so you cannot enumerate the indexes. A wildcard index indexes *paths* rather than one named field: ``` db.products.createIndex({ "attributes.$**": 1 }) ``` Every field path found under `attributes` — `attributes.color`, `attributes.voltage`, `attributes.dimensions.width` — is recorded, so a filter on any one of them can seek into the index without anyone having declared it in advance. ## The forms - **Subtree**: `{ "<path>.$**": 1 }` indexes everything under that path. This is the form to prefer; it keeps the index scoped to the part of the document that is genuinely dynamic. - **Whole document**: `{ "$**": 1 }` indexes every field path in every document. Broad and expensive. - **Filtered whole-document**: `{ "$**": 1 }` with the `wildcardProjection` option to include or exclude specific paths. This option applies only to the all-fields form — a subtree wildcard is already scoped, so it does not take one. Arrays inside the wildcard's scope are handled by the usual multikey rules: one key per element. ## What it does not give you This is the substance of a senior answer, because the temptation is to treat it as "index everything and stop thinking": - **One path per query.** A wildcard index does not behave like a compound index across two dynamic fields. A filter on `attributes.color` and `attributes.size` uses the index for one of them and re-checks the other against the fetched documents. If both predicates are unselective, that is a lot of fetching. - **Larger and write-heavier.** Every indexed path in every document produces keys. A wide, deeply nested document generates many; inserts and updates maintain them all. - **Option restrictions.** A wildcard index cannot be unique, cannot be a TTL index, and cannot be used as the index backing a shard key. It also cannot be declared as another special type such as text or geospatial. - **Compound form is limited.** In MongoDB 7.0 you can build a compound wildcard index — ordinary keys plus a wildcard term — but exactly one term may be the wildcard. That form is useful for the multi-tenant shape, where a tenant id is a known field and everything under a custom-attributes subtree is not. - **Only documents containing the path are indexed.** A document without the path contributes nothing for it, which matters when you expect the index to help a query looking for the absence of a field. ## How to decide Ask whether the field names are stable. If your queries are the same handful of shapes hitting the same handful of fields, name those fields and build targeted indexes — they will be smaller, cheaper and able to serve compound predicates and sorts properly. Reach for a wildcard index when the set of queryable fields is genuinely open-ended and the alternative is either no index at all or a growing pile of one-off indexes created reactively as new attributes appear. A useful middle path in the dynamic case is the attribute-pattern shape: instead of `attributes: { color: "red", size: "L" }`, store `attributes: [ { k: "color", v: "red" }, { k: "size", v: "L" } ]` and build one ordinary compound index on `attributes.k` and `attributes.v`. That gives a genuine compound index over a dynamic attribute set, at the price of a less natural document shape. ## Answering well Give the one legitimate use case — field names as data — then immediately show you know the limits: one indexed path per query, no unique, no TTL, no shard key, one wildcard term in a compound form. Finish by naming the alternative you would consider first, which is either targeted indexes on the stable fields or the key/value attribute array.