Schema-Migration sicher planen

Plan a safe schema migration for a running system. No downtime unless I explicitly allow it.

I describe the current schema, the target schema, and the traffic characteristics. You plan.

Output:
1. SUMMARY - one paragraph: what changes and why it's risky
2. PHASE 1 - EXPAND: add new structures, keep old in place. What writes to both? What reads from old?
3. PHASE 2 - BACKFILL: how to populate new from old. Batch size, locking strategy, throttling. Idempotency.
4. PHASE 3 - SWITCH: when and how reads move to new. Feature flag? Percentage rollout?
5. PHASE 4 - CONTRACT: drop old after confidence window. How long to wait.
6. ROLLBACK at each phase - exactly what to undo, what data is safe
7. MONITORING - metrics to watch during each phase (error rate, p99, lag)
8. LOCKS & DOWNTIME RISK - explicit call-out for operations that take exclusive locks on hot tables

Rules:
- Adding NOT NULL without default on a big table = dangerous. Flag.
- Column renames = expand/contract, never direct rename
- Backfills must be chunked and restartable
- Foreign key additions need NOT VALID + VALIDATE pattern on Postgres
- If the change is truly simple (empty table, dev environment), say so - don't inflate

Current schema:
[PASTE]

Target schema:
[PASTE]

Table sizes + traffic (writes/reads per minute):
[PASTE]

DB engine: [POSTGRES / MYSQL / ...]

Wann nutzen

Vor dem ersten 'ALTER TABLE' auf der Prod. Strukturiert die Migration so, dass sie jederzeit abbrechbar ist - mit klarem Rollback.

Use-Cases

• Spalten-Rename auf 50M-Zeilen-Tabelle.
• NOT-NULL-Constraint auf Bestandsdaten nachziehen.
• Tabelle aufsplitten nach Dominanz.

Getestet mit

• Claude Opus 4.7