Das Deployment ist grün – aber verträgt die Datenbank zwei App-Versionen gleichzeitig?

Freitag, 14:08 Uhr. Die CI ist grün. Die Datenbankmigration ist erfolgreich durchgelaufen. Die neue Anwendungsversion startet. Trotzdem steigen plötzlich 500er-Fehler.

Der Grund ist nicht zwingend eine kaputte Migration. Vielleicht war sie technisch korrekt – aber nicht kompatibel mit dem Zustand während des Deployments.

Bei einem Rolling Deployment laufen alte und neue Instanzen für eine Übergangszeit nebeneinander. Kubernetes beschreibt genau dieses Verhalten: Ein neues ReplicaSet wird schrittweise hochskaliert, während das alte heruntergefahren wird. Auch Blue-Green-Deployments, mehrere Server hinter einem Load Balancer oder langsame Prozess-Neustarts erzeugen denselben Grundzustand: Für einige Minuten können zwei Softwareversionen dieselbe Datenbank verwenden.

Wenn eine Migration in diesem Moment eine Spalte umbenennt, entfernt oder semantisch verändert, kann die neue Version funktionieren, während die alte noch Requests verarbeitet – oder umgekehrt.

Die entscheidende Release-Frage lautet deshalb nicht nur:

"Läuft die Migration durch?"

Sondern:

"Kann das Schema während des gesamten Rollouts mit der alten und der neuen Anwendungsversion gleichzeitig arbeiten?"

Eine Datenbankmigration ist Teil des Releases, nicht dessen Vorwort

Viele Deployment-Pipelines behandeln Migrationen wie eine vorbereitende Formalität:

1. Migration ausführen.
2. Anwendung deployen.
3. Healthcheck grün.
4. Fertig.

Dieses Modell funktioniert bei kleinen, rein additiven Änderungen oft gut. Es wird fragil, sobald ein Release bestehende Spalten entfernt, Datentypen ändert, große Tabellen scannt, neue Constraints validiert oder Indizes auf produktiven Tabellen erzeugt.

PostgreSQL dokumentiert ausdrücklich, dass die benötigte Sperrstufe von der konkreten ALTER TABLE-Operation abhängt und standardmäßig ein ACCESS EXCLUSIVE-Lock verwendet wird, sofern für die jeweilige Unterform nichts anderes angegeben ist. Ein ACCESS EXCLUSIVE-Lock kollidiert mit allen anderen Tabellen-Lockmodi; PostgreSQL weist außerdem darauf hin, dass genau dieser Modus auch normale SELECT-Zugriffe blockieren kann.

Das bedeutet nicht, dass ALTER TABLE in Produktion grundsätzlich gefährlich ist. Es bedeutet: "DDL" ist keine ausreichende Risikobeschreibung. Die konkrete Operation, Tabellengröße, vorhandene Transaktionen und Lock-Dauer entscheiden.

Das Zwei-Versionen-Problem

Nehmen wir eine Tabelle users mit der Spalte full_name.

Die neue Anwendung soll künftig display_name verwenden. Eine direkte Migration könnte die Spalte einfach umbenennen. Technisch ist das sauber. Operativ kann es trotzdem brechen:

• alte Instanzen fragen weiterhin full_name ab,
• die Migration benennt die Spalte in display_name um,
• neue Instanzen funktionieren,
• alte Instanzen werfen Fehler, bis sie vollständig aus dem Traffic verschwunden sind.

Ein schneller Rollout verkleinert das Fenster. Er beseitigt es nicht zuverlässig.

Noch unangenehmer wird es beim Rollback. Kubernetes kann eine Deployment-Revision auf eine ältere Pod-Template-Version zurücksetzen. Die Datenbank wird dadurch nicht automatisch in ihren vorherigen Zustand zurückversetzt. Wenn das neue Release bereits eine von der alten Anwendung benötigte Spalte gelöscht hat, kann der "Rollback" der App sofort in die nächste Störung laufen.

Ein App-Rollback ist nur dann wirklich ein Rollback, wenn die alte App mit dem aktuellen Datenbankschema noch funktionieren kann.

Das robuste Muster: Expand, Migrate, Contract

Für Änderungen an stark genutzten produktiven Schemas ist ein mehrstufiges Vorgehen oft wesentlich belastbarer.

Phase 1: Expand

Erweitern Sie das Schema so, dass bestehende Clients weiter funktionieren.

Beim Beispiel full_name → display_name würde das bedeuten:

• neue Spalte hinzufügen,
• bestehende Spalte zunächst behalten,
• neue Anwendung so bauen, dass sie mit beiden Zuständen umgehen kann.

Eine additive Änderung ist nicht automatisch risikofrei – auch das Hinzufügen einer Spalte kann Locking und andere Effekte haben. Aber die Datenmodell-Idee ist entscheidend: Die alte Schnittstelle wird noch nicht entfernt.

Phase 2: Anwendung kompatibel deployen

Die neue Version kann für eine Übergangszeit beispielsweise:

• in beide Felder schreiben,
• bevorzugt aus display_name lesen,
• bei noch nicht migrierten Datensätzen auf full_name zurückfallen.

Welche Variante sinnvoll ist, hängt von Konsistenzanforderungen und Datenvolumen ab. Wichtig ist, dass der Übergang explizit modelliert wird und nicht von der Hoffnung abhängt, dass alle Prozesse gleichzeitig wechseln.

Phase 3: Daten kontrolliert migrieren

Bestehende Datensätze werden in Batches in das neue Feld überführt.

Ein Backfill sollte nicht einfach "alle zehn Millionen Zeilen in einer Transaktion" bedeuten. Prüfen Sie unter anderem:

• Batch-Größe,
• Transaktionsdauer,
• I/O- und Replikationslast,
• Lock-Wartezeiten,
• Fehler- und Wiederholungsstrategie,
• Fortschrittsmessung,
• Verhalten bei parallelen neuen Writes.

Der Backfill ist ein Betriebsjob. Er verdient Monitoring wie ein Deployment.

Phase 4: Reads umschalten und beobachten

Wenn die Daten vollständig migriert sind, liest die Anwendung ausschließlich aus dem neuen Feld. Die alte Spalte bleibt noch vorhanden.

Jetzt kann gemessen werden:

• Gibt es noch Writes auf das alte Feld?
• Greift irgendein Worker, Cronjob oder älterer Service darauf zu?
• Existieren Reports, Exporte, BI-Jobs oder Integrationen, die das alte Schema noch verwenden?
• Sind Fehlerquoten und Datenkonsistenz stabil?

Phase 5: Contract

Erst wenn die alte Schnittstelle nachweislich nicht mehr gebraucht wird, wird sie entfernt.

Das Löschen der alten Spalte gehört idealerweise in ein späteres Release. Dadurch wird aus einer schwer zurückrollbaren Ein-Schritt-Änderung eine Folge kleinerer, beobachtbarer Entscheidungen.

Locking: Der Fehler, den Staging oft nicht zeigt

Eine Migration kann auf Staging in 80 Millisekunden laufen und in Produktion minutenlang warten.

Warum? Staging hat vielleicht 50.000 Datensätze, kaum Traffic und keine lange laufenden Transaktionen. Produktion hat 40 Millionen Zeilen, Queue-Worker, Reports, Imports und mehrere gleichzeitig aktive Services.

PostgreSQL zeigt die relevanten Locks über pg_locks. Für einen Release-Audit ist aber nicht nur wichtig, welcher Lock nach einem Problem sichtbar wird. Die Pipeline sollte vorab wissen, welche Lock-Stufe die konkrete Operation anfordert.

Praktische Fragen sind:

• Welche Tabellen sind betroffen?
• Wie groß sind sie real?
• Welche Lock-Stufe benötigt jede Anweisung?
• Kann die Anweisung auf eine bereits laufende Transaktion warten?
• Was passiert mit neuen Requests, während sie wartet?
• Gibt es ein lock_timeout oder ein bewusstes Abbruchverhalten?
• Kann ein abgebrochener Migrationslauf sauber erneut gestartet werden?

Eine Migration, die unbegrenzt auf den perfekten Moment wartet, kann im ungünstigsten Fall eine Warteschlange aus nachfolgenden Requests erzeugen.

Indizes: "CREATE INDEX" ist nicht immer eine harmlose Nebenoperation

Neue Features brauchen häufig neue Indizes. Auf einer großen produktiven Tabelle kann ein normaler Index-Build den Schreibverkehr blockieren.

PostgreSQL bietet deshalb CREATE INDEX CONCURRENTLY. Laut aktueller Dokumentation erlaubt diese Variante normale Inserts, Updates und Deletes während des Builds, benötigt dafür aber mehr Arbeit, mehrere Scans und kann auf bestehende Transaktionen warten. Scheitert ein Concurrent-Build, kann außerdem ein ungültiger Index zurückbleiben, der bereinigt oder erneut aufgebaut werden muss.

Daraus folgt eine wichtige Betriebsregel:

"Concurrent" bedeutet nicht "kostenlos" und nicht "unkaputtbar". Es bedeutet eine andere Lock- und Ausführungsstrategie.

Ein Audit sollte deshalb auch für Indexmigrationen prüfen:

• ob der ORM-Generator wirklich die gewünschte SQL-Variante erzeugt,
• ob die verwendete Migrationstransaktion CONCURRENTLY überhaupt zulässt,
• wie ein abgebrochener Build erkannt wird,
• ob ungültige Indizes im Monitoring auffallen,
• wie CPU-, I/O- und Replikationslast während des Builds überwacht werden.

Constraints: Validieren muss nicht dasselbe sein wie Einführen

Ein neuer Foreign Key oder Check-Constraint kann auf einer großen bestehenden Tabelle eine vollständige Prüfung der Altbestände erfordern.

PostgreSQL unterstützt für bestimmte Constraint-Typen NOT VALID. Dabei wird die potenziell lange Prüfung bestehender Zeilen zunächst übersprungen, während neue oder geänderte Datensätze den Constraint bereits erfüllen müssen. Die spätere VALIDATE CONSTRAINT-Operation scannt den Bestand separat und verwendet laut PostgreSQL einen SHARE UPDATE EXCLUSIVE-Lock.

Das ist kein universelles Rezept für jede Migration. Es zeigt aber das Grundprinzip sehr gut:

Schemaänderung, Datenvalidierung und endgültige Durchsetzung müssen nicht immer in einem einzigen großen Release-Schritt passieren.

Rollback planen, bevor Sie ihn brauchen

"Wir können jederzeit die vorige Version deployen" ist nur die halbe Aussage.

Vor einer Schemaänderung sollte für jedes Release klar sein:

• Kann die alte Anwendung mit dem neuen Schema lesen?
• Kann sie damit schreiben?
• Sind neue Spalten optional oder setzt die neue Version bereits Daten voraus, die die alte nicht kennt?
• Wurde eine Spalte, Tabelle oder Enum-Variante entfernt?
• Wurde Dateninhalt irreversibel transformiert?
• Kann eine Reverse-Migration Daten verlieren?
• Muss bei Problemen vorwärts repariert werden statt zurückzurollen?

Besonders gefährlich sind automatische "down migrations", die formal den alten Schema-Zustand herstellen, dabei aber Daten löschen, die das neue Release bereits geschrieben hat.

Ein belastbarer Rollback-Plan unterscheidet deshalb zwischen:

Application rollback: alte Binär-/Container-Version wieder aktivieren.

Schema rollback: Datenbankschema zurücksetzen.

Data rollback: bereits transformierte oder neu geschriebene Daten zurücksetzen.

Diese drei Dinge sind nicht dasselbe und sollten nicht so behandelt werden.

Ein pragmatischer Release-Check

Vor dem Deployment:

1. Das tatsächlich erzeugte SQL prüfen, nicht nur den Namen der ORM-Migration.
2. Für jede Operation Lock-Stufe, möglichen Tabellen-Scan und erwartete Laufzeit bewerten.
3. Gegen produktionsnahe Datenmengen testen.
4. Prüfen, ob alte und neue App-Version gleichzeitig mit dem expandierten Schema funktionieren.
5. Backfills von DDL trennen, wenn sie groß oder langlaufend sind.
6. Rollback-Kompatibilität dokumentieren.
7. Kritische Nutzerwege als Smoke- oder End-to-End-Test vorbereiten.

Während des Deployments:

• Lock-Wartezeiten und lange Transaktionen beobachten,
• Datenbankverbindungen und Query-Latenzen beobachten,
• Fehlerraten nach Anwendungsversion unterscheiden,
• Backfill-Fortschritt und Abbrüche sichtbar machen,
• den Rollout stoppen können, bevor die Contract-Phase begonnen hat.

Nach dem Deployment:

• prüfen, ob alte Prozesse noch auf die alte Schemaform zugreifen,
• Datenkonsistenz stichprobenartig verifizieren,
• erst nach einer Beobachtungsphase alte Spalten, Tabellen und Kompatibilitätscode entfernen,
• Cleanup als eigenes Release behandeln.

Die gefährlichste Migration ist oft nicht die komplizierteste

Ein komplexer Datenumbau bekommt meist Aufmerksamkeit. Eine kleine Änderung wie "Spalte umbenennen", "NOT NULL setzen" oder "Index ergänzen" rutscht dagegen leicht als Einzeiler durch den Review.

Gerade diese Änderungen können produktiv unangenehm werden, weil ihr Risiko nicht im SQL-Text sichtbar ist, sondern im gleichzeitigen Zustand des Systems:

• alte und neue Anwendungsversionen,
• reale Datenmenge,
• parallele Transaktionen,
• Replikation,
• Hintergrundjobs,
• externe Integrationen,
• Rollback-Pfade.

Datenbankmigrationen sind deshalb kein isoliertes Datenbankthema. Sie sind Release-Engineering.

Was Website-Pflichtencheck dabei prüfen würde

Bei einem technischen Release- und Wartbarkeitscheck kann Website-Pflichtencheck den Migrationspfad als Teil des gesamten Betriebs untersuchen:

• Reihenfolge von Migration, Deployment und Backfills,
• tatsächlich erzeugte SQL-Migrationen,
• potenzielle Sperr- und Tabellen-Scan-Risiken,
• Kompatibilität zwischen alter und neuer Anwendungsversion,
• Rolling-, Blue-Green- oder Multi-Instance-Verhalten,
• Index- und Constraint-Strategien,
• idempotente Wiederholbarkeit fehlgeschlagener Schritte,
• Rollback- und Forward-Fix-Plan,
• Monitoring für Locks, Fehler und Backfills,
• Cleanup alter Schemaelemente,
• funktionale Tests nach dem Release.

Das Ziel ist nicht, jede Migration in einen dreiwöchigen Prozess zu verwandeln. Bei kleinen Websites darf ein Deployment klein bleiben.

Aber sobald eine Website oder SaaS-Anwendung laufende Nutzer, Bestellungen, Anfragen, Mandate, Buchungen oder andere produktive Daten verarbeitet, sollte eine Schemaänderung eine Frage zuverlässig beantworten können:

Was passiert, wenn das Deployment nicht in einer einzigen atomaren Sekunde stattfindet?

Wenn die Antwort lautet "Dann darf nur nichts schiefgehen", fehlt noch ein Teil des Release-Designs.

Quellen

• PostgreSQL 18: ALTER TABLE — https://www.postgresql.org/docs/current/sql-altertable.html
• PostgreSQL 18: Explicit Locking — https://www.postgresql.org/docs/current/explicit-locking.html
• PostgreSQL 18: CREATE INDEX — https://www.postgresql.org/docs/current/sql-createindex.html
• Kubernetes: Deployments — https://kubernetes.io/docs/concepts/workloads/controllers/deployment/