Ein Softwareupdate braucht eine Übergangsphase.

Während des Updates arbeiten zwei Versionen

Wenn Sie individuelle Software weiterentwickeln, gehört der Übergang zwischen zwei Versionen zur eigentlichen Entwicklungsaufgabe. Das wird besonders wichtig, sobald sich auch die Datenbankstruktur ändert. Unsere Empfehlung: Planen Sie ausdrücklich, welche Kombination aus Anwendung und Datenbank während jeder Etappe funktionieren muss.

Kubernetes beschreibt für schrittweise Updates, wie alte Anwendungsinstanzen nach und nach durch neue ersetzt werden. Dabei können unterschiedliche Versionen gleichzeitig laufen. Nutzen beide dieselbe Datenbank, muss deren Struktur während dieses Übergangs zu beiden passen. Daraus folgt für die Planung: Prüfen Sie auch den Zwischenzustand, in dem bereits neue Software läuft und die alte noch Anfragen bearbeitet.

Beispiel: Eine Pflichtangabe in mehreren Etappen

Beispielablauf: Eine individuell entwickelte Serviceanwendung soll künftig zu jedem Vorgang eine Kategorie speichern. Bisher existiert diese Angabe nicht. Im ersten Schritt ergänzt das Entwicklungsteam eine Datenbankspalte, die zunächst leer bleiben darf. Die neue Anwendung erfasst Kategorien bei neuen Vorgängen und kann vorhandene Einträge ohne Kategorie weiterhin anzeigen.

Anschließend werden bestehende Vorgänge zugeordnet. Eindeutige Fälle lassen sich nach festgelegten Regeln bearbeiten; unklare Fälle kommen zur fachlichen Prüfung. Solange alte Programmversionen noch Vorgänge ohne Kategorie anlegen können, darf die Datenbank diese Angabe nicht zwingend verlangen. Erst wenn alle schreibenden Programme umgestellt und sämtliche fehlenden Zuordnungen geklärt sind, folgt die verbindliche Datenbankregel.

Diese Reihenfolge entspricht dem von GitLab dokumentierten Vorgehen beim Ergänzen einer NOT-NULL-Bedingung: Zuerst werden die erforderlichen Anwendungsänderungen ausgerollt, danach folgt die strengere Datenbankregel. Der Nutzen für Sie liegt in getrennt prüfbaren Schritten. Voraussetzung ist eine vollständige Übersicht über alle Programme, die in die betroffene Tabelle schreiben.

Eine kurze Änderung kann die Datenbank beschäftigen

Auch die technische Durchführung braucht Planung. PostgreSQL 17 verlangt für viele Änderungen mit ALTER TABLE eine exklusive Tabellensperre. Welche Sperre tatsächlich nötig ist, hängt von der konkreten Operation ab. Die Kürze eines Änderungsbefehls sagt deshalb wenig über seine Auswirkungen im laufenden Betrieb aus.

Für bestimmte Regeln lässt sich die Arbeit aufteilen: Fremdschlüssel- und CHECK-Bedingungen können zunächst mit NOT VALID angelegt werden. Neue beziehungsweise geänderte Datensätze müssen die Regel dann bereits erfüllen; bestehende Daten werden später mit VALIDATE CONSTRAINT geprüft. Das ist kein allgemeiner Schalter für unterbrechungsfreie Änderungen. Lassen Sie Sperrverhalten und Laufzeit für Ihre konkrete Datenbankversion untersuchen.

Große Datenbestände brauchen überprüfbare Teilschritte

Bei umfangreichen Beständen empfiehlt sich eine gesonderte Planung der Datenumstellung. GitLab dokumentiert dafür Hintergrundmigrationen in Teilmengen. Die einzelnen Arbeitsschritte sollen klein und wiederholbar sein: Eine Wiederholung nach einem Fehler muss die Datenintegrität erhalten. Außerdem nennt die Dokumentation Datenmenge, Laufzeit und zusätzliche Datenbanklast als wichtige Prüfgrößen.

Für den Beispielablauf empfehlen wir eine Fortschrittsanzeige mit bearbeiteten Vorgängen, offenen Zuordnungen und Fehlern. Legen Sie fest, wer bei widersprüchlichen Kategorien entscheidet und unter welchen Bedingungen die Verarbeitung pausiert. Prüfen Sie vor dem Abschluss den tatsächlichen Datenzustand. Diese zusätzliche Arbeit lohnt besonders dann, wenn ein großer Bestand während der Umstellung weiter genutzt werden soll.

Der Rückweg hat eine technische Grenze

Kubernetes setzt beim Rollback eines Deployments dessen Pod-Vorlage zurück, also die Vorlage für die ausgeführten Container. Bereits vorgenommene Datenbankänderungen werden dadurch nicht automatisch rückgängig gemacht. Unsere Schlussfolgerung: Ein erfolgreicher Anwendungsrollback belegt noch nicht, dass die vorherige Version mit dem inzwischen erreichten Datenzustand arbeiten kann.

Dokumentieren Sie deshalb für jede Etappe, bis zu welcher Anwendungsversion ein Rückwechsel geprüft wurde. Im Beispiel gehört dazu ein Schreibversuch mit der alten Version nach Einführung der Pflichtangabe. Sobald diese Version die neue Regel nicht erfüllen kann, ist ein bloßer Austausch der Anwendung kein ausreichender Rückweg.

Beginnen Sie mit einer konkreten Änderung

Unser Vorschlag für den ersten Schritt: Wählen Sie eine anstehende Datenbankänderung Ihrer eigenen Anwendung. Halten Sie auf einer Seite die beteiligten Programme, die Reihenfolge der Etappen, die Abschlusskriterien und die verantwortlichen Personen fest. Erproben Sie den Ablauf mit synthetischen Daten in realistischer Größenordnung. Prüfen Sie dabei ausdrücklich eine Unterbrechung und anschließende Fortsetzung.

Eine offene Datenbank wie PostgreSQL liefert dafür nachvollziehbare technische Grundlagen. Die Entscheidung über den Aufwand bleibt projektspezifisch: Für eine kleine interne Anwendung kann ein vereinbartes Wartungsfenster angemessener sein als ein aufwendiger Parallelbetrieb. Eine unterbrechungsfreie Umstellung lässt sich aus dem beschriebenen Vorgehen allein nicht garantieren.

Recherchestand: 23. September 2026. Die PostgreSQL-Aussagen beziehen sich auf Version 17. Die verlinkten Kubernetes- und GitLab-Seiten werden fortlaufend aktualisiert; konkrete Abläufe müssen zur eingesetzten Version passen.