PostgreSQL 14 EOL: Sicher auf PostgreSQL 18 migrieren

Ein PostgreSQL-14-Upgrade gehört erst ins Wartungsfenster, wenn das Team einen vollständigen Restore unter Zeitmessung abgeschlossen und die Anwendung erfolgreich verbunden hat. Eine vorhandene Backup-Datei reicht nicht. Erst der gestartete Test-Cluster belegt, dass die Datendateien, die benötigten WAL-Segmente, die Erweiterungen und die Konfiguration zusammenpassen.

PostgreSQL 14 erreicht am 12. November 2026 sein End of Life. Der Restore-first-Ansatz verlagert die Freigabe vom Upgrade-Befehl auf überprüfbare Ergebnisse: Restore, Point-in-Time-Recovery (PITR), Checksum-Einstellungen und Rückweg stehen vor dem Cutover fest.

Warum das PostgreSQL 14 EOL jetzt Maßnahmen verlangt

Der Community-Support für eine PostgreSQL-Hauptversion läuft normalerweise etwa fünf Jahre und umfasst Fehlerkorrekturen sowie Sicherheitsupdates. Nach dem 12. November 2026 erhält PostgreSQL 14 keine regulären Korrekturen mehr. Neu entdeckte Schwachstellen oder Fehler bei Replikation und Recovery werden dann in diesem Versionszweig nicht mehr behoben.

Für dieses Runbook ist PostgreSQL 18 der Zielzweig. Das Team verwendet beim Cutover das dann aktuelle Minor-Release dieses Zweigs und prüft vorab die Release Notes, die Plattformpakete und die Kompatibilität aller Erweiterungen. Eine fest eingetragene Minor-Version veraltet mit dem nächsten Fehlerkorrektur-Release. RTO, RPO und Abbruchschwellen müssen deshalb vor der technischen Vorbereitung feststehen.

Freigabekriterien vor dem Upgrade festlegen

Ein reserviertes Wartungsfenster ist noch keine Freigabe. Das Team startet das PostgreSQL-14-Upgrade erst, wenn Backup, WAL-Archivierung, PITR und Rückweg in einer isolierten Umgebung funktioniert haben.

Das Recovery Point Objective (RPO) nennt den maximal akzeptierten Datenverlust in Minuten oder Sekunden
Das Recovery Time Objective (RTO) begrenzt die Zeit vom Ausfall bis zur verfügbaren Datenbank
Benannte Verantwortliche dokumentieren die technische Freigabe, die Anwendungsprüfung und die Rollback-Entscheidung
Abbruchschwellen stoppen den Cutover bei fehlenden WAL-Dateien, Fehlern von pg_upgrade oder überschrittenem Zeitbudget

Die Abnahmekriterien benennen außerdem konkrete Transaktionen, Schnittstellen und Berichte, die nach dem Start von PostgreSQL 18 geprüft werden. Eine vollständige Bestandsaufnahme liefert dafür die technische Ausgangslage.

PostgreSQL-14-Umgebung inventarisieren

Ein Test-Cluster liefert nur dann übertragbare Ergebnisse, wenn Betriebssystem, PostgreSQL-Patchstand, Erweiterungen und Tablespaces der Produktion entsprechen. Auch die Komponenten außerhalb des Datenverzeichnisses gehören in die Inventur.

Die verwendeten JDBC- oder ODBC-Treiber und Connection-Pools
Die Backup-Agenten und ihre Zugriffsrechte
Die Monitoring-Erweiterungen und externen Prüfungen
Die Replikations-Slots, Publikationen und Subskriptionen
Die geplanten Jobs und externen Scheduler

SHOW server_version;
SHOW data_checksums;

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

SELECT spcname, pg_tablespace_location(oid)
FROM pg_tablespace
ORDER BY spcname;

Für jede Erweiterung müssen das Paket, die Shared Library und eine mit PostgreSQL 18 kompatible Version verfügbar sein. Das betrifft beispielsweise PostGIS, pg_cron und Module aus shared_preload_libraries. Das PostgreSQL-Training für Administratoren behandelt die Installation, die Berechtigungen und die Wartung solcher Komponenten. Nach der Inventur bestimmt die Checksum-Einstellung die Initialisierung des Ziel-Clusters.

Data Checksums vor initdb abgleichen

SHOW data_checksums; liefert auf dem PostgreSQL-14-Quell-Cluster den Wert on oder off. PostgreSQL 18 aktiviert Data Checksums bei neu initialisierten Clustern standardmäßig. pg_upgrade verlangt übereinstimmende Einstellungen für den alten und den neuen Cluster.

Bei einer Quelle ohne Checksums wird der PostgreSQL-18-Cluster mit initdb --no-data-checksums initialisiert. Eine Quelle mit Checksums benötigt ein Ziel mit aktivierten Checksums. Soll der PostgreSQL-14-Cluster vor dem Upgrade auf Checksums umgestellt werden, läuft pg_checksums --enable bei gestopptem Server über das gesamte Datenverzeichnis.

pg_checksums --enable -D /srv/pg14/data

Die Laufzeit dieser Umstellung gehört in die Planung, weil der Cluster währenddessen offline bleibt. Nach der dokumentierten Checksum-Entscheidung kann der physische Backup-Test beginnen.

Beweisen, dass sich das Backup wiederherstellen lässt

Ein erfolgreich beendetes pg_basebackup bestätigt zunächst den Kopiervorgang. Das Backup-Manifest erfasst die erwarteten Dateien und ihre Prüfsummen. pg_verifybackup erkennt fehlende oder nachträglich veränderte Dateien.

pg_basebackup -h SOURCE_HOST -U replicator \
  -D /backup/pg14-base -X stream -c fast \
  --manifest-checksums=SHA256 --progress

pg_verifybackup /backup/pg14-base

Die Verifikation ersetzt keinen Restore. Der Restore-Test verwendet ein isoliertes Datenverzeichnis, startet das Backup mit PostgreSQL-14-Binaries und führt fachliche Kontrollabfragen aus. Erst dieser laufende Cluster bildet einen belastbaren Ausgangspunkt für den PITR-Test.

WAL-Archivierung und Point-in-Time-Recovery testen

Das physische Backup enthält den Datenbestand seines Sicherungszeitraums und die WAL-Dateien, die für einen konsistenten Start benötigt werden. Eine Wiederherstellung auf einen späteren Zeitpunkt gelingt nur, wenn alle weiteren WAL-Segmente das Archiv erreicht haben, lesbar sind und über restore_command abgerufen werden.

restore_command = 'cp /archive/%f %p'
recovery_target_time = 'YYYY-MM-DD HH:MI:SS+TZ'
recovery_target_action = 'pause'

Bei PostgreSQL 14 aktiviert eine Datei namens recovery.signal den Recovery-Modus. Sie liegt im wiederhergestellten Datenverzeichnis.

touch /restore/pg14/recovery.signal

Eine Testtabelle mit fortlaufender ID macht das Ergebnis prüfbar: Ein Datensatz vor dem Recovery Target muss vorhanden sein, ein später geschriebener Datensatz darf noch nicht erscheinen. Die gemessene Dauer wird mit dem RTO verglichen. Das Training zu PostgreSQL-Datensicherung und Datenintegrität behandelt physische Backups, WAL-Archivierung und Recovery-Planung. Nach dem Recovery-Nachweis folgt der Vorabtest des Upgrades.

pg_upgrade --check unter Cutover-Bedingungen ausführen

Der Vorabtest verwendet dieselben PostgreSQL-18-Binaries, Erweiterungspakete, Datenverzeichnisse und Transferoptionen wie der spätere Cutover. Die Parallelisierung mit --jobs wird mit einer zur Testplattform passenden Prozesszahl gemessen.

/opt/postgresql/18/bin/pg_upgrade \
  --old-bindir=/opt/postgresql/14/bin \
  --new-bindir=/opt/postgresql/18/bin \
  --old-datadir=/srv/pg14/data \
  --new-datadir=/srv/pg18/data \
  --check --jobs=JOB_COUNT

Fehlende Libraries, inkompatible Erweiterungen und Hinweise auf problematische Datentypen werden vor dem Wartungsfenster behoben. Die Dateien postgresql.conf und pg_hba.conf benötigen einen Versionsvergleich, weil ein unverändertes Kopieren veraltete oder nicht mehr unterstützte Parameter übernehmen kann. Danach lässt sich der Transfermodus anhand der gemessenen Dauer, des Speicherbedarfs und des Rückwegs auswählen.

Migrationsmethode und Transfermodus auswählen

Dump und Restore erzeugen die Datenbankobjekte neu, benötigen bei großen Clustern jedoch meist mehr Zeit. pg_upgrade übernimmt die vorhandenen Datendateien und verkürzt dadurch den Versionswechsel. Der gewählte Transfermodus verändert den Speicherbedarf und den möglichen Rückweg.

Vergleich der Migrationsmethoden und Transfermodi für PostgreSQL 18
Methode	Speicher und Dauer	Folge für den Rollback
Dump und Restore	Der Neuaufbau benötigt zusätzlichen Speicher und verlängert das Wartungsfenster	Die Quelle bleibt unverändert
`pg_upgrade` mit Dateikopie	Alle Relationsdateien werden in den Ziel-Cluster kopiert	Der alte Cluster bleibt getrennt erhalten
`--link`	Hardlinks sparen Kopierzeit und zusätzlichen Speicher	Nach dem Start des neuen Clusters ist das alte Datenverzeichnis keine sichere Rollback-Quelle mehr
`--clone`	Copy-on-Write setzt die Unterstützung durch das Dateisystem voraus	Spätere Änderungen an beiden Clustern bleiben in getrennten Blöcken erhalten

Kein Transfermodus ersetzt ein externes, mit Restore geprüftes Backup. Sobald Anwendungen auf PostgreSQL 18 schreiben, weichen Quelle und Ziel voneinander ab. Der Rollback-Plan muss deshalb festlegen, wie das Team die seit dem Cutover geschriebenen Transaktionen sichert oder zurückführt. Die gewählte Methode bestimmt damit auch den Umfang der Validierung nach dem Serverstart.

PostgreSQL 18 nach dem Cutover validieren

Der erfolgreiche Serverstart bestätigt weder die Berechtigungen noch die Anwendungsfunktionen. Die Abnahme verbindet technische Prüfungen mit fachlichen Kontrollwerten.

Anwendungsabfragen und Schreibtests für die wichtigsten Transaktionen
Zeilenzahlen und fachliche Summen für festgelegte Tabellen
Sequenzstände und Identity-Spalten nach neuen Schreibvorgängen
Rollen, Zugriffsrechte und installierte Erweiterungsversionen
Geplante Jobs, Replikation, Monitoring und Anwendungspools

PostgreSQL 18 übernimmt bei pg_upgrade die Optimizer-Statistiken der übertragenen Relationen. Kritische lesende Abfragen verdienen trotzdem einen Vergleich mit EXPLAIN (ANALYZE, BUFFERS), weil geänderte Einstellungen oder Erweiterungsversionen andere Pläne erzeugen können. Tabellen mit erkennbar veralteten Statistiken werden anschließend mit ANALYZE aktualisiert.

Die alte Umgebung oder eine unabhängige Wiederherstellung bleibt erhalten, bis alle technischen und fachlichen Prüfungen abgeschlossen sind. Damit beginnt das vereinbarte Rollback-Fenster.

Alte Umgebung bis zur Abnahme behalten

Ein erfolgreicher Funktionstest beendet das Rollback-Fenster noch nicht. Die Anwendungsteams bestätigen ihre Abnahmekriterien, während Monitoring, Replikation und Integritätsprüfungen über den vereinbarten Beobachtungszeitraum ohne offene Fehler laufen.

Ein neues PostgreSQL-18-Backup wird innerhalb dieses Zeitraums ebenfalls wiederhergestellt. Beim Transfer mit --link übernimmt eine externe Sicherung die Funktion des Rückfallbestands, sobald der neue Cluster gestartet wurde. Erst nach dem Ende des Rollback-Fensters und der vollständigen Abnahme wird die Quelle entfernt. Die finale Checkliste bündelt die dafür benötigten Nachweise.

Finale Checkliste für das PostgreSQL-Upgrade

Erfasse Version, Betriebssystem, Cluster-Größe, Tablespaces, Erweiterungen und Abhängigkeiten
Gleiche die Data-Checksum-Einstellungen von Quelle und Ziel ab
Erzeuge ein physisches Backup mit Manifest und führe pg_verifybackup aus
Starte einen vollständigen Restore und miss die Wiederherstellungsdauer
Spiele archivierte WAL-Dateien bis zum definierten Recovery Target ein
Führe pg_upgrade --check mit den vorgesehenen PostgreSQL-18-Binaries aus
Dokumentiere den Transfermodus, das Wartungsfenster und das Rollback-Verfahren
Validiere Anwendungen, Datenintegrität, Berechtigungen, Jobs und Abfragepläne
Bewahre Befehlsausgaben, Zeitmessungen und Abnahmeprotokolle auf

Das Runbook ist abgeschlossen, sobald die gemessenen Restore- und PITR-Zeiten, die Prüfausgaben und die Abnahmeentscheidung an einem Ort vorliegen. Lege als nächsten Schritt einen isolierten PostgreSQL-14-Restore an und miss die Zeit bis zur ersten erfolgreichen Anwendungsabfrage.