What must an updateOne or deleteOne on a sharded collection include in its filter, and what changed in MongoDB 7.0?

## Why single-document writes are special A read that lacks the shard key is merely expensive: the router asks everyone and merges. A write with `multi: false` is different, because it must be applied to **exactly one** document on **exactly one** shard. Sending it to all shards would risk applying it more than once. That asymmetry is the root of every rule below. ## The historical rule For a long time MongoDB refused the ambiguous case outright. On a sharded collection, `updateOne`, `replaceOne`, `deleteOne` and `findAndModify` had to include the **shard key** or the **`_id`** field in the query filter, or the operation failed with an error about the query needing to contain the shard key. Teams worked around it by carrying the shard key into every write path, or by doing a find-then-write in application code — which is exactly the two-step the server later took over. Note what `_id` bought you there: it did not make the write *targeted*, since the router still could not map an `_id` to a shard, but it did guarantee that at most one document cluster-wide could match, which is enough to make the operation unambiguous. ## What MongoDB 7.0 changed MongoDB 7.0 added support for `updateOne`, `deleteOne` and `findAndModify` **without the shard key**. The filter may now name any field. Under the hood the cluster performs the work the application used to do by hand: it locates a matching document across the shards, then applies the write to that one document on the shard that owns it, with the appropriate protections so the write lands once. This is a usability win, not a performance one. The operation costs a cluster-wide search plus a second phase to apply the write, so it is strictly more expensive than the targeted form. Treat it as an escape hatch for occasional writes and admin paths, not as permission to stop carrying the shard key on hot write paths. ## Upserts are still stricter An upsert has a branch where **no document matches** and a new one is created. Creating a document requires knowing which chunk — and therefore which shard — it belongs to, and that requires a complete shard-key value. There is nothing to search for and nothing to infer. So an upsert on a sharded collection must supply the full shard key in the query filter, and by extension the shard-key fields must be present in the resulting document. Design upsert-based write paths (idempotent ingestion, counters, last-seen timestamps) with the shard key in the natural business key, or they will not work at all. ## Multi-document writes `updateMany` and `deleteMany` have no such restriction, in any version. They are allowed to affect any number of documents, so broadcasting is semantically fine: the router sends the operation to every shard that could hold matches, and each applies it locally. If the filter does contain the shard key, the same targeting rules as reads apply and the operation goes only to the relevant shards. Be aware that a broadcast multi-write is not atomic across shards — each shard's portion commits independently unless the operation runs inside a multi-document transaction. ## Practical guidance - Carry the shard key on every hot write path. If the value exists in the request context, thread it into the repository call; that is usually a one-line change that converts a cluster-wide operation into a single-shard one. - Design keys so that natural upsert paths include the full shard key. - When you must write without the key, make it a low-rate path, and know that you are paying a search plus an apply. - When reviewing a migration to a sharded collection, audit every `updateOne`/`findAndModify` call site: on pre-7.0 clusters these fail loudly, and on 7.0+ they succeed quietly at N times the cost, which is the more dangerous of the two failure modes.