db-migration-guardianlisted

# db-migration-guardian A migration that "works on my machine" can still take production down by holding an `ACCESS EXCLUSIVE` lock on a hot table for 40 seconds, or by deleting a column the currently-deployed code still selects. This skill makes the safe path the default: every schema change is decomposed into steps that are individually backwards-compatible, lock-aware, and reversible. ## Use this BEFORE - Any `ALTER TABLE` on a table a live deployment reads or writes. - Adding/removing/renaming a column, changing a type, adding a constraint or index. - Any data backfill that touches more than a few thousand rows. If the table is genuinely unused by anything running, you can skip the ceremony — but confirm that first, don't assume it. ## The core rule: expand → migrate → contract Never change a column's meaning in one deploy. Split every breaking change across at least two deploys so the old and new code both work against the intermediate schema. 1. **Expand** — add the new shape *additively* (new nullable column, new table, new index). Old code ignores it; new code can start writing it. Deploy code that writes both old and new. 2. **Migrate** — backfill existing rows into the new shape in batches. Switch reads to the new shape. Deploy code that reads new, still writes both. 3. **Contract** — once nothing reads or writes the old shape, drop it. Deploy code that only uses the new shape, then run the drop migration. A rename is never `RENAME COLUMN` on a live table — it