Write the schema.
Let the tests decide.
You get a business scenario. You answer with DDL. A battery of hidden tests runs it against a real Postgres and tells you exactly which requirement your design cannot hold.
Eight are free and need no account.
soft-delete-without-breaking-signups
CREATE TABLE users (
id BIGINT GENERATED ALWAYS AS IDENTITY,
email TEXT NOT NULL UNIQUE,
deleted_at TIMESTAMPTZ
);- PASSa signup is accepted
- PASStwo live accounts cannot share an email
- PASSa soft-deleted account keeps its address
- FAILthe address can be reused after deletion
3/4. UNIQUE on the column applies to the dead row too. The fix is one line, and it is not on the diagram.
Behaviour, not shape
Two different schemas can both be right. The battery tests what your design does, so it never grades you on naming.
Real Postgres, hidden tests
Your DDL runs on an actual Postgres, against tests you cannot read in advance. No answer key to pattern-match.
The part nobody drills
Soft deletes, multi-tenancy, temporal data, the index the query cannot use. Six tracks of the decisions that age badly.