Datenbankmigrations-Planer

Das Problem

Sie muessen eine Spalte umbenennen, aber Ihre App bedient 10.000 Anfragen pro Minute. Ein naives ALTER TABLE sperrt die Tabelle, bricht Verbindungen ab und nimmt Ihren Service offline. Datenbankmigrationen sind der gefaehrlichste Teil jedes Deployments — sie sind irreversibel, datenzerstoerend und betreffen die kritischste Komponente. Eine falsche Migration kann Daten korrumpieren, Rueckwaertskompatibilitaet brechen oder Tabellen stundenlang sperren.

Der Prompt

Du bist ein Datenbankmigrations-Experte spezialisiert auf Zero-Downtime-Schema-Aenderungen. Plane meine Migration sicher.

MIGRATIONSDETAILS:
- Datenbank: [z.B. PostgreSQL 16, MySQL 8, MongoDB 7]
- ORM/Tool: [z.B. Prisma, Knex, Django ORM, TypeORM, Raw SQL]
- Benoetigte Aenderung: [z.B. Spalte umbenennen, NOT NULL-Spalte hinzufuegen, Tabelle aufteilen, Datentyp aendern]
- Tabellengroesse: [z.B. 1 Mio Zeilen, 100 Mio Zeilen, unbekannt]
- Traffic waehrend Migration: [z.B. read-heavy, write-heavy, gemischt, Wartungsfenster moeglich]
- Replikations-Setup: [z.B. einzelner Primary, Primary + Read Replicas, Multi-Primary]

Plane die Migration:
1. **Risikobewertung**: Bewerte die Gefahrenstufe (niedrig/mittel/hoch/kritisch) und erklaere warum.
2. **Mehrphasen-Strategie**: Teile die Migration in sichere Phasen mit dem Expand-Contract-Pattern auf.
3. **Rueckwaertskompatibilitaet**: Stelle sicher, dass alte und neue Code-Versionen waehrend des Uebergangs funktionieren.
4. **Daten-Backfill**: Wie neue Spalten/Tabellen befuellt werden ohne Sperren oder Ueberlastung der Datenbank.
5. **Rollback-Plan**: Wie jede Phase rueckgaengig gemacht wird wenn etwas schiefgeht.
6. **Monitoring**: Welche Datenbank-Metriken waehrend der Migration zu beobachten sind.
7. **Migrations-Skripte**: Der exakte SQL- oder ORM-Migrationscode fuer jede Phase.

Beispielausgabe

Migration: Spalte "name" → "full_name" in Users-Tabelle umbenennen (50 Mio Zeilen)
Risiko: HOCH — direktes Umbenennen sperrt Tabelle, bricht alle Queries die "name" referenzieren

Phase 1 (Deploy 1): Neue Spalte hinzufuegen
  ALTER TABLE users ADD COLUMN full_name VARCHAR(255);
  — Alte ("name") und neue ("full_name") Spalten existieren parallel

Phase 2 (Deploy 2): Dual-Write im Anwendungscode
  — In beide Spalten schreiben, aus "name" lesen (alter Code kompatibel)

Phase 3 (Hintergrund): Bestehende Daten nachfuellen
  — UPDATE users SET full_name = name WHERE full_name IS NULL (Batches von 10.000)

Phase 4 (Deploy 3): Lese-Umstellung auf neue Spalte
Phase 5 (Deploy 4): Alte Spalte entfernen

Wann einsetzen

Verwenden Sie diesen Skill fuer jede Schema-Aenderung an einer Produktionsdatenbank mit Live-Traffic — Spaltenumbenennungen, Typwechsel, NOT NULL-Constraints, Tabellen-Splits oder -Zusammenfuehrungen. Besonders kritisch bei Tabellen mit Millionen von Zeilen, wo ALTER TABLE-Operationen minutenlang sperren koennen.

Profi-Tipps

• Fuegen Sie nie eine NOT NULL-Spalte ohne Default hinzu — bei grossen Tabellen schreibt ALTER TABLE ADD COLUMN NOT NULL jede Zeile neu und sperrt die Tabelle. Fuegen Sie die Spalte zuerst als nullable hinzu, fuellen Sie nach, dann setzen Sie das Constraint.
• Testen Sie Migrationen gegen produktionsgrosse Daten — eine Migration die in 2 Sekunden auf Ihrer Dev-Datenbank mit 100 Zeilen laeuft, sperrt eventuell 30 Minuten auf Produktion mit 50 Millionen Zeilen.
• Verwenden Sie Advisory Locks fuer Backfill-Skripte — verhindern Sie dass mehrere Backfill-Prozesse gleichzeitig laufen, was die Datenbank ueberlasten kann.
• Haben Sie immer einen getesteten Rollback — ueben Sie den Rollback auf Staging bevor Sie auf Produktion ausfuehren. “Wir koennen ja vom Backup wiederherstellen” ist kein Rollback-Plan, sondern ein Gebet.