The database is part of the system, not a detail

It's easy to treat the database as plumbing, something you point the app at and forget. In practice it's where your real rules and your real risk live. The schema is a design document, whether you wrote it down or not.

Decide things once, in the right place

Put the constraint where it can actually be enforced. A uniqueness rule belongs in the database, not in a hope that two requests never race. Postgres has had transactions and constraints for decades, so use them.

• Model the important rules with constraints, not just application code.
• Treat migrations as code, reviewed and reversible like any other change.
• Keep reads and writes honest about what the database actually guarantees.

Get this right and the app gets simpler, because it can finally trust the layer underneath it.