Constraints aren't chains, they're seatbelts.

We recently read an article arguing against database constraints. It made some interesting points... but we disagree.

Strongly.

The “dumb database” argument goes like this:
- “Validation is business logic; it belongs in the application layer, not the database.”
- “Constraints duplicate logic.”
- “They  slow down testing and limit flexibility.”
- "Skipping them speeds up development, especially early on when the schema is still evolving"

OMG!

That might work if your database serves only one app, written only by you. But in reality, applications are messy. They are like monkeys, if you leave them alone in a room, they will throw everything at the wall.

Databases often outlive code. Enforcing integrity only in the application only works if your application is the only thing that will touch that database from now until the heat death of the universe.

In the real world, databases will get accessed by integrations, other services, developers on consoles, etc, all capable of writing bad data if you let them. There is a kind of “Law of Data” at play: any unconstrained combination of values will eventually appear in your database.

Declarative constraints protect your data at its source. They don't duplicate logic, they define what valid data even means.

Declarative also means it is harder to mess it up and have bugs as compared to application-level validation.

Why constraints matter:
✅ Data integrity: Stop corruption before it starts.
✅ Security: Bad data is a vulnerability.
✅ Simplicity: Cleaner code, safer assumptions.
✅ Evolution: Modern ORMs work with constraints.
✅ Independence: Multiple clients, one source of truth.
✅ Performance: Databases are optimized for this.

Unlimited flexibility sounds great… until it corrupts your data and your clients grab pitchforks. Losing that kind of “freedom” is a feature, not a bug. Unlimited flexibility also means unlimited complexity, and that is a big cause of project failure.

You don't need to move all business logic to the database, but your database should be smart enough to save you from bad data.