If the application already validates every field before saving, why still declare constraints such as NOT NULL, unique keys and foreign keys in the database schema?

## Two different jobs The question sounds like a choice; it is not. Application validation and database constraints are two controls with different guarantees, and mature systems run both. **Application validation is a user-experience feature.** It runs before the round trip, can report every problem on a form at once, produces messages in the user's language, and can express rules that depend on things the database cannot see — the caller's permissions, a feature flag, a pricing policy, a third-party service. It is also where rules that change monthly belong, because changing code is cheaper than migrating a schema. **Database constraints are a correctness guarantee.** They are enforced by the engine on every write regardless of origin, evaluated atomically with the write, and they cannot be forgotten by a code path that did not know about them. ## Why the application cannot carry the guarantee alone **It is not the only writer.** Even in a strictly single-service architecture, the tables are also written by data migrations, backfill scripts, an admin console, a support engineer running a manual UPDATE at 2 a.m., an ETL import, a restore, and eventually a second service someone adds. None of those execute your validation layer. The set of writers only grows over the system's lifetime. **Validation and write are not atomic.** Any rule of the form 'check the state, then write' has a window between the two steps in which another transaction can change that state. Uniqueness is the canonical example, but the shape recurs for balance checks, capacity limits and status transitions. A constraint has no window: the engine evaluates it as part of applying the write. **Code paths multiply and drift.** A new endpoint, a bulk operation, a retry handler, a test fixture that writes directly, an ORM that patches a subset of columns — each is an opportunity to skip a validator. Deploys make this worse: during a rolling release two versions run at once, and only one of them may know the new rule. **Data outlives applications.** Schemas commonly survive multiple rewrites of the code above them. Whatever invariants exist only in the application are lost with it, and the next team inherits a table whose real shape they must reverse-engineer from the data. ## The secondary benefits, which are not small **Documentation that cannot rot.** A NOT NULL, a unique key or a CHECK in the schema is a statement about the domain that is guaranteed to be true, unlike a comment or a wiki page. New engineers read the schema first. **Optimizer information.** Planners use constraints. Knowing a column is unique changes join cardinality estimates and enables plan shapes; knowing a column is NOT NULL removes NULL-handling branches; a validated CHECK can eliminate impossible predicates or prune partitions. Declared constraints often make queries faster, not just safer. **Cheaper incident response.** When a class of corruption is impossible, it never appears in an incident. The cost of finding and repairing bad data after the fact usually dwarfs the write-time cost of the constraint by orders of magnitude. ## The honest costs Constraints are not free and a good answer says so. They add work to every write, most visibly foreign keys and unique indexes. They make some schema changes and bulk loads slower or more involved. They produce errors the application must catch and translate, and an uncaught constraint violation surfacing as a 500 with a raw database message is a real, common defect. Rules that change frequently are painful to keep in the schema, because changing them is a migration rather than a deploy. Those costs argue for choosing *which* rules to encode, not for skipping the layer. The usual dividing line: stable structural invariants — identity, referential integrity, mandatory fields, value domains — go in the schema; volatile policy goes in code. ## What 'defense in depth' means here A useful mental model: the application check is the guard rail that makes the common path pleasant, and the constraint is the wall that makes the bad outcome impossible. You do not remove the wall because the guard rail is working, and you do not remove the guard rail because the wall exists — hitting the wall produces an error the user should rarely see. The corollary is that the write path must handle constraint violations gracefully rather than treat them as impossible. If your validation is correct they are rare, but rare is not never: a race, a stale read, a retry, or a rule the application does not know about will all surface as a violation. Map the constraint name to a user-facing message and, where the operation is naturally idempotent, treat the violation as a normal outcome rather than an error. ## The one-sentence answer Application validation makes the good path fast and friendly; database constraints make the bad path impossible for every writer, including the ones you have not written yet.