Zero-Downtime Migration & Rollback

Plan a schema change that can ship while the old application version is still running and still serving traffic.

CURRENT SCHEMA: {paste relevant tables}
DESIRED CHANGE: {describe}
DATABASE: {Postgres version, roughly how many rows}
DEPLOYMENT: {rolling / blue-green / single instance}

Return:

1. WHY THE NAIVE VERSION BREAKS — what happens to in-flight requests from the old code if you just run the obvious ALTER. Be specific about which statement takes which lock and what it blocks.

2. THE STEPS — numbered, each safe to deploy alone, each leaving both old and new code working:
   - the SQL
   - the lock it takes and for how long, on this row count
   - what must be deployed before it and what after
   - how to verify before moving on

3. BACKFILL — if data must be filled, how to do it in batches without holding a long transaction, and how to resume it after an interruption.

4. ROLLBACK — for each step, how to undo it. Mark clearly the first step that becomes irreversible, because that is the point where the plan stops being safe.

5. WHAT I WOULD CHECK IN PRODUCTION before calling it done, as queries not feelings.