What is the difference between validationLevel strict and moderate in MongoDB?
answer
- one axis is which writes get checked
- the other axis is what failure does
- inserts are checked either way
- the exemption is for already-broken documents
- it exists so you can retrofit onto legacy data
basics
~20 svalidationLevel decides which writes are checked. strict, the default, validates every insert and update. moderate validates inserts and updates to documents that already satisfy the validator, but skips updates to documents that currently fail it. off disables validation.
solid answer
~40 s`validationLevel` controls **which documents** the validator is applied to, not how harshly it is applied. With `"strict"` — the default — every insert and every update must produce a conforming document. With `"moderate"`, inserts are still fully checked, and so are updates to documents that already satisfy the validator, but an update to a document that currently violates it is let through unchecked. There is also `"off"`, which disables validation entirely while leaving the validator definition in place. `moderate` exists for retrofitting: you can add rules to a collection full of legacy documents without breaking the code paths that still update those legacy documents, then move to `strict` once they have been backfilled. The trap is reading `moderate` as "complain but allow" — that is `validationAction`, a separate setting.
go deeper
Recall that strict is the default and checks every write, and that a second value, moderate, exists for collections holding older documents that do not match the rules.
Explain the three values precisely, and above all that moderate exempts updates to already-non-conforming documents while still validating every insert. Keep it distinct from validationAction.
Show you have used moderate as a migration tool: which population is exempt, why documents ratchet one way, and how you confirm the collection's options after a collMod rather than assuming them.
Frame the levels as a rollout policy: what the organization's default is for new collections, who may set a collection to off and for how long, and how that decision is reviewed.
## Two independent knobs A MongoDB collection with a validator also carries two options that decide how the validator is used. They are frequently confused, so it helps to name what each one answers: - `validationLevel` — *which writes get checked at all.* Values: `"strict"` (default), `"moderate"`, `"off"`. - `validationAction` — *what happens when a checked write fails.* Values: `"error"` (default), `"warn"`. This section is about the first. Both are set on `createCollection` or changed later with `collMod`, and both are visible in `db.getCollectionInfos({ name: "orders" })` under `options`. ## strict `"strict"` is the default and means what it sounds like: every insert and every update is validated against the resulting document. If the document that the write would leave behind does not match the validator, the write is subject to `validationAction`. There is no exemption for documents that were already stored, already broken, or written before the validator existed — the moment anything updates such a document, the update must produce a conforming result. That is the right setting for a collection that has been validated since day one. It is a painful setting to switch on for a collection with a decade of accumulated shapes, because ordinary updates to old documents — a `$set` of one field on a document missing three others — will suddenly start failing. ## moderate `"moderate"` relaxes *which documents* are checked, not *which rules* apply: - **Inserts** are always validated in full. New garbage still cannot get in. - **Updates to a document that already satisfies the validator** are validated in full. A conforming document cannot be degraded into a non-conforming one. - **Updates to a document that does not currently satisfy the validator** are not validated. The write goes through whatever shape it produces. That third bullet is the whole point. It draws a line between the population you have cleaned up and the population you have not, and it lets both keep working. Your fixer script can rewrite a legacy document in stages without being blocked, and the legacy code path that `$set`s one field on an old order keeps functioning while you migrate. Note the asymmetry it creates: a non-conforming document stays non-conforming as far as the server is concerned until some write happens to make it conform, at which point it joins the checked population and can never regress. Documents ratchet in one direction. ## off `"off"` disables validation while keeping the validator definition stored on the collection. It is useful as an escape hatch during an incident — turn validation off, unblock writes, investigate — and as a way of keeping a documented schema attached to a collection that you are not yet ready to enforce. It is not a good steady state, because the schema in the collection options gradually stops describing the data and nobody notices. ## The classic confusion Candidates routinely answer that `moderate` means "log the problem but allow the write". It does not. Under `moderate` with the default `validationAction: "error"`, a non-conforming **insert** is still rejected outright. Logging-instead-of-rejecting is `validationAction: "warn"`, and the two settings compose: `moderate` + `warn` is the most permissive combination short of `off`, `strict` + `error` is the strictest. ## Setting and changing it ```js db.runCommand({ collMod: "orders", validator: { $jsonSchema: { bsonType: "object", required: ["customerId"] } }, validationLevel: "moderate", validationAction: "warn" }) ``` One caution about `collMod`: the command replaces the collection's validation options with what you send. If you issue a `collMod` that changes the `validator` but omits `validationLevel`, do not assume the previous level silently persists — read the collection's options back after the change and confirm the three fields hold what you intended. A schema you believe is enforced but is actually running at a level you did not choose is worse than no schema at all, because it buys false confidence. ## Where levels fit in an interview answer The expected shape of a good answer is: name the three values, state that the axis is *which documents* rather than *which rules*, explain that `moderate` exists for retrofitting onto dirty data, and separate it cleanly from `validationAction`. If you can add that documents ratchet — once a document conforms, `moderate` stops letting it regress — you are well past the bar.
- Under validationLevel moderate, can a document that currently conforms be updated into a non-conforming state?No. moderate validates updates to documents that already satisfy the validator, so a conforming document cannot be degraded. Only documents that already fail the validator are exempt. The practical effect is a one-way ratchet: as the backfill fixes documents they enter the checked population and stay there.
- Does validationLevel moderate mean non-conforming inserts are allowed through with a warning?No — that conflates the two settings. moderate still fully validates every insert, and with the default validationAction of "error" a bad insert is rejected. Allowing a failing write to proceed while logging it is validationAction: "warn", which is configured separately and composes with any level.
- What is validationLevel "off" for, given the validator stays attached?It is an escape hatch: it stops all checking without discarding the schema definition, so you can unblock writes during an incident or attach a documented schema you are not ready to enforce, then switch back with collMod. As a steady state it is poor, because the stored schema quietly drifts away from the real data.
saying these in an interview costs you the question
- Says moderate means 'warn instead of reject' — that is validationAction
- Thinks moderate relaxes which rules apply rather than which documents
- Believes moderate lets non-conforming inserts through
- Assumes strict rescans and rejects existing stored documents
- Cannot name off as the third validationLevel value