PostgreSQL 14 erhält ab November 2026 keinen Support mehr: Upgrade auf 17 oder 18?

PostgreSQL 17 ist die erste Wahl, wenn Produktionsrisiken und Erweiterungskompatibilität Vorrang haben; PostgreSQL 18 ist die bessere Option, wenn Anwendung, Treiber und Erweiterungen geprüft sind und ein konkretes neues Merkmal benötigt wird. PostgreSQL 14 sollte vor dem Supportende migriert werden: Die offizielle Lebenszyklusübersicht nennt den 12.11.2026 als letzten Supporttag. PostgreSQL-Versionierung und Supportfristen

Dieser Leitfaden richtet sich an DBA, die PostgreSQL 14 betreiben und Versionen, Änderungsfreigaben sowie Wiederherstellung verantworten.
Auch Backend- und Datenteams finden hier einen Ablauf, um Kompatibilität, Wartungsfenster und Rückfall vor der Produktionsumstellung zu prüfen.

Zuletzt aktualisiert am 21.10.2026; geprüft anhand der offiziellen PostgreSQL-Lebenszyklusübersicht sowie der Versions- und Upgrade-Dokumentation.

PostgreSQL-14-Upgrade: PostgreSQL 17 oder 18 nach Kriterien wählen

Die Versionswahl sollte an den Folgen für den Betrieb ausgerichtet werden, nicht allein am Veröffentlichungsdatum. PostgreSQL 17 bietet ein zusätzliches Jahr Support gegenüber PostgreSQL 18 weniger, ist aber für Teams eine sinnvolle Zielversion, wenn sie die Einführung neuer Änderungen begrenzen und Erweiterungen konservativ validieren wollen. PostgreSQL 18 ist geeigneter, wenn ein benötigtes Merkmal die zusätzliche Prüfung rechtfertigt und alle Abhängigkeiten für die Zielversion bestätigt sind.

Die offiziellen Lebenszyklusangaben, geprüft am 21.10.2026, führen PostgreSQL 14.24 mit Support bis zum 12.11.2026, PostgreSQL 17.11 bis zum 08.11.2029 und PostgreSQL 18.6 bis zum 14.11.2030. Die konkreten Nebenversionen werden weiterentwickelt; vor einem Wartungsfenster ist daher erneut zu prüfen, welche unterstützte Nebenversion aktuell bereitsteht. Die offizielle Versionsübersicht und die Veröffentlichungsnotizen für PostgreSQL 18.6 sind dafür maßgeblich.

Die Tabelle ersetzt keine Prüfung der konkreten Anwendung. Eine Erweiterung kann in einer Testumgebung verfügbar sein, aber im Produktionsbetrieb wegen Paketstand, Betriebssystem oder Abhängigkeiten abweichen. Umgekehrt ist PostgreSQL 18 nicht automatisch riskant: Das Risiko entsteht, wenn die zusätzliche Änderung ungeprüft eingeführt wird oder die Organisation den Nutzen des neuen Merkmals nicht benennen kann.

Die Veröffentlichungsnotizen zu PostgreSQL 18 sollten deshalb Teil der Freigabeunterlagen sein. Prüfen Sie insbesondere Hinweise, die bestehende Konfigurationen, Erweiterungen oder Abläufe betreffen. Die Supportdauer ist ein Planungswert, kein Ersatz für diese technische Prüfung.

Kompatibilität als Freigabekriterium behandeln

Ein Hauptversionswechsel betrifft mehr als den Datenbankserverprozess. Vor der Zielversionsentscheidung sollte ein vollständiges Abhängigkeitsverzeichnis vorliegen. Dazu gehören die Anwendungsbibliotheken und Datenbanktreiber, Verbindungspools, Erweiterungen, Betriebssystempakete, Überwachungsagenten, Sicherungswerkzeuge sowie Skripte für Deployment und Wartung.

Für PostgreSQL 18 sind die offiziellen Versionshinweise zusätzlich auf Migrationshinweise und Änderungen zu prüfen. Eine bestandene Installation oder ein erfolgreicher Start des Servers reicht als Freigabe nicht: Kritische Abfragen, Schreibvorgänge, Indexnutzung, geplante Jobs und die Beobachtbarkeit müssen unter den Bedingungen der Zielversion getestet werden. Für jede verwendete Erweiterung sind Version, Bezugsquelle, Upgrade-Schritt und verantwortliches Team festzuhalten. Ist ein benötigtes Paket für die Zielversion nicht verfügbar oder ist sein Verhalten ungeklärt, ist die Migration nicht freigabereif.

Auch regionale Einstellungen und Kollationen gehören in die Prüfung. Abweichungen zwischen Systembibliotheken oder Gebietsschema können Vergleiche und Sortierungen beeinflussen; Tests sollten daher nicht nur die Datenbankstruktur, sondern auch fachlich relevante Such- und Sortierergebnisse abdecken. Führen Sie die Prüfung in einer isolierten Umgebung mit einer aktuellen Datenkopie aus und halten Sie fest, welche Tests bestanden wurden, welche Abweichungen offen sind und wer sie akzeptiert.

Ein Beitrag im PostgreSQL-14-zu-18-Migrationsgespräch der Community zeigt, dass die direkte Zielwahl und der Upgrade-Pfad Nutzer beschäftigen. Das ist ein Signal für den praktischen Informationsbedarf, aber kein Beleg für allgemeine Erweiterungskompatibilität. Diese muss für die eigene Installation nachgewiesen werden.

Upgrade-Pfad und Unterbrechungsrisiko getrennt bewerten

Die Migrationsmethode ist von der Zielversion zu unterscheiden. Sie hängt unter anderem vom verfügbaren Wartungsfenster, Datenvolumen, Änderungsrate, Rückfallmodell und davon ab, ob die Anwendung während der Vorbereitung weiterarbeiten muss.

Die Dokumentation zu pg_upgrade beschreibt die Voraussetzungen und Prüfoptionen des Werkzeugs. Die übergreifende PostgreSQL-Dokumentation zu Upgrades hilft, den Ablauf für den gewählten Versionspfad einzuordnen. Für einen Wechsel mittels logischer Replikation gelten eigene Anforderungen; berücksichtigen Sie dafür die Dokumentation zum Upgrade mit logischer Replikation.

Keine dieser Methoden garantiert eine bestimmte Unterbrechungsdauer. Bei pg_upgrade hängt das Wartungsfenster beispielsweise nicht nur vom Kopiervorgang ab: Vorprüfungen, Konfigurationsänderungen, Anwendungsabnahme und Entscheidung über einen Rückfall gehören ebenfalls dazu. Ermitteln Sie die Dauer deshalb durch einen vollständigen Probelauf mit einer repräsentativen Datenkopie. Bei logischer Replikation müssen Sie zusätzlich Umschaltung und Konsistenz der relevanten Objekte testen, nicht nur den Replikationsstatus beobachten.

Betriebshinweis: Ein erfolgreicher Start der neuen Hauptversion ist noch keine Abnahme. Die Freigabe sollte erst erfolgen, wenn fachliche Schreib- und Leseabläufe, Erweiterungen, Überwachung und eine Wiederherstellung geprüft sind.

Entscheidung als bedingte Freigabe festhalten

Nutzen Sie die folgenden Bedingungen im Änderungsantrag. Sie verhindern, dass die Wahl einer Zielversion nur mit dem Wunsch nach „der neuesten Version“ begründet wird.

• PostgreSQL 17 wählen, wenn Erweiterungen und Anwendung für 17 validiert sind, PostgreSQL 18 kein notwendiges Merkmal liefert und das Team das Änderungsrisiko klein halten möchte.
• PostgreSQL 18 wählen, wenn Anwendung, Treiber, Betriebspakete und Erweiterungen für 18 erfolgreich geprüft sind und ein konkreter Funktionsbedarf dokumentiert ist.
• Noch keine Zielversion freigeben, wenn für eine geschäftskritische Erweiterung kein unterstütztes Paket oder kein verlässlicher Upgrade-Pfad feststeht. Zuerst Abhängigkeit klären oder ersetzen, danach erneut entscheiden.
• Den Cutover verschieben und die Vorbereitung eskalieren, wenn die Generalprobe nicht abgeschlossen ist, die Wiederherstellung nicht funktioniert oder der Rückfall nicht rechtzeitig entschieden werden kann. Ein ungetesteter Wechsel kurz vor Supportende ist kein belastbarer Zeitplan.

Diese Bedingungen sind auch für den Fall wichtig, dass der Support von PostgreSQL 14 bereits endet, bevor die Migration abgeschlossen ist. Die Datenbank wird dadurch nicht automatisch abgeschaltet. Der Betrieb einer nicht mehr unterstützten Version bedeutet jedoch, dass reguläre Korrekturen ausbleiben; der Übergang muss daher als zeitlich begrenzte Risikomaßnahme mit Verantwortlichem, Schutzmaßnahmen und festem Ablöseplan dokumentiert werden. Sie sollten nicht aus einer verzögerten Migration ableiten, dass der Altstand dauerhaft vertretbar sei.

Migration in überprüfbaren Meilensteinen durchführen

Ein verlässlicher Upgrade-Plan hat benannte Freigabepunkte. Der Ablauf lässt sich an die jeweilige Umgebung anpassen; die Nachweise sollten jedoch vor dem Produktionswechsel vorliegen.

1. Bestand aufnehmen. Dokumentieren Sie aktuelle PostgreSQL-Nebenversion, Betriebssystem, Erweiterungen, Treiber, Verbindungspools, Datenbanken, Rollen, Sicherungsjobs und externe Abhängigkeiten. Erfassen Sie auch die wichtigsten Anwendungsabläufe und Abfragen, die nach dem Wechsel geprüft werden müssen.

2. Zielversion und Supportfenster bestätigen. Prüfen Sie die aktuelle offizielle Lebenszyklusübersicht unmittelbar vor der Entscheidung. Wählen Sie PostgreSQL 17 als konservative Ausgangsoption, wenn der Nutzen von PostgreSQL 18 nicht konkret belegt ist. Wählen Sie 18 erst nach Prüfung der passenden Versionshinweise und Abhängigkeiten.

3. Sicherung und Wiederherstellung nachweisen. Erstellen Sie eine Sicherung, die außerhalb des betroffenen Servers verfügbar ist, und stellen Sie sie in einer isolierten Umgebung wieder her. Eine Sicherungsdatei, deren Wiederherstellung nicht getestet wurde, ist kein Nachweis für einen funktionierenden Rückfall. Die offizielle PostgreSQL-Dokumentation zu Sicherung und Wiederherstellung beschreibt die verfügbaren Verfahren; das Team muss daraus ein zur eigenen Umgebung passendes Verfahren festlegen.

4. Generalprobe mit repräsentativer Kopie ausführen. Führen Sie den vorgesehenen Migrationsweg einschließlich Vorprüfungen, Konfigurationsanpassungen, Erweiterungs-Upgrades, Start und Anwendungstests aus. Messen Sie die vollständige Ablaufdauer im eigenen System, statt eine pauschale Zeitangabe zu übernehmen. Protokollieren Sie Fehler und wiederholen Sie den Test nach deren Behebung.

5. Abnahmekriterien und Rückfall vorab festlegen. Bestimmen Sie, welche Anwendungsfunktionen erfolgreich sein müssen, wer die Freigabe erteilt und an welchem Punkt ein Rückfall ausgelöst wird. Halten Sie außerdem fest, wie neue Schreibvorgänge behandelt werden, falls die Zielumgebung verworfen wird. Ein Rückfall, der Datenänderungen verliert oder nicht konsistent ausgeführt werden kann, muss vorab als Risiko behandelt werden.

6. Produktionswechsel kontrolliert durchführen. Setzen Sie den vereinbarten Schreibstopp oder die Replikationsumschaltung um, führen Sie die dokumentierten Prüfungen aus und lassen Sie die Anwendung erst nach Freigabe weiterarbeiten. Beobachten Sie danach Fehlerprotokolle, Verbindungen, Hintergrundjobs und die fachlich wichtigen Abläufe.

7. Altstand und Sicherungen erst nach Abnahme bereinigen. Bewahren Sie den Rückfallpfad so lange auf, wie es die interne Änderungsfreigabe verlangt. Entfernen Sie alte Datenbestände nicht unmittelbar nach einem erfolgreichen Serverstart; zuerst müssen Wiederherstellung, Datenvollständigkeit und Anwendungsergebnisse bestätigt sein.

Die Reihenfolge ist kein Ersatz für eine projektspezifische Betriebsanweisung. Sie stellt sicher, dass die Freigabe nicht allein an einem erfolgreichen technischen Upgrade hängt, sondern auch an einer nachgewiesenen Wiederherstellung und fachlichen Abnahme.

Speicher, Ausfallschutz und Serverressourcen gemeinsam planen

Die nötige Kapazität lässt sich nicht seriös allein aus der PostgreSQL-Hauptversion ableiten. Für die Planung zählen Datenbestand, Wachstum, Sicherungsaufbewahrung, temporärer Platz für Migration, Wiederherstellungsanforderungen und gleichzeitige Last. Prüfen Sie vor dem Wechsel, ob Daten und temporäre Arbeitsbereiche während der Migration nebeneinander Platz finden; leiten Sie daraus die erforderliche Speicherkonfiguration ab, statt nur die derzeit belegte Datenmenge anzusetzen.

Wenn die PostgreSQL-14-Migration Teil einer Neuplanung ist, kann eine dedizierte Maschine die Ressourcenzuteilung vereinfachen. Bei CloudUDP sind laut Konfigurationsübersicht Systeme mit 128 oder 256 GB ECC-Arbeitsspeicher sowie zwei direkt angebundenen NVMe-Laufwerken mit je 1 TB aufgeführt; zusätzliche NVMe-Laufwerke sind dort ebenfalls als Option beschrieben. Diese Angaben sind eine mögliche Hardwarebasis, aber keine Empfehlung für eine bestimmte Datenbankgröße und kein Leistungsversprechen. Der Bedarf muss anhand der eigenen Daten, Sicherungsstrategie und Generalprobe bestimmt werden.

Die Laufwerke sind nicht durch Hardware-RAID abgesichert. Bei einer solchen Konfiguration müssen Sie Ausfallschutz selbst planen, beispielsweise mit Software-Spiegelung oder Replikation, und Sicherungen außerhalb des Servers aufbewahren. Ein RAID-Verbund ersetzt keine Sicherung: Er schützt nicht vor versehentlichem Löschen, fehlerhaften Datenänderungen oder einem nicht wiederherstellbaren Migrationsfehler. Die gewählte Schutzstrategie muss deshalb sowohl den Laufwerksausfall als auch Wiederherstellung und Rückfall des Upgrade-Verfahrens abdecken.

Planen Sie die Bedienung ebenfalls in den Änderungsprozess ein. Für den Zugriff auf ein gemietetes System beschreibt die CloudUDP-Zugangsanleitung den vorgesehenen Administrationszugang. Stellen Sie vor Beginn sicher, dass berechtigte Personen Zugriff haben und die Betriebsdokumentation die notwendigen Schritte abdeckt. Bei einer Datenbank mit sensiblen Informationen sollten zusätzlich Zugriffskontrolle, Protokollierung und die Anforderungen der DSGVO in den Freigabeprozess einfließen.

FAQ zu Supportende, Versionswahl und Wartungsfenster

Kann PostgreSQL 14 nach dem Supportende weiterlaufen?

Technisch kann ein bestehender Server weiterlaufen; das Supportende schaltet die Datenbank nicht automatisch ab. Nach dem 12.11.2026 erhält PostgreSQL 14 laut offizieller Lebenszyklusübersicht jedoch keine regulären Fehler- und Sicherheitskorrekturen mehr. Planen Sie deshalb nicht mit einem unveränderten Dauerbetrieb, sondern legen Sie einen Migrationstermin fest und prüfen Sie bis dahin Sicherung, Zugriffsbeschränkungen und mögliche Übergangsmaßnahmen.

Ist PostgreSQL 17 oder PostgreSQL 18 das bessere direkte Upgrade-Ziel?

PostgreSQL 17 ist die vorsichtigere Vorauswahl, wenn breite Anwendungskompatibilität und ein überschaubares Änderungsrisiko Priorität haben. PostgreSQL 18 ist passend, wenn Anwendung, Treiber und Erweiterungen auf der Zielversion geprüft wurden und ein konkretes neues Merkmal benötigt wird. Entscheidend ist nicht die Versionsnummer allein, sondern das Ergebnis einer Migration unter realistischen Bedingungen einschließlich Rücksicherung.

Welche Erweiterungen sind vor dem Wechsel auf PostgreSQL 18 zu prüfen?

Erstellen Sie eine vollständige Liste der installierten Erweiterungen und ihrer Versionen, einschließlich Erweiterungen, die automatisch durch Anwendungen oder Betriebspakete eingebunden wurden. Prüfen Sie für jede Erweiterung, ob ein passendes Paket für das Zielsystem und die Zielversion verfügbar ist, ob ein Upgrade-Schritt erforderlich ist und ob Funktionen, Datentypen sowie Indizes nach der Migration korrekt arbeiten. Eine erfolgreiche Installation auf einem anderen System belegt keine allgemeine Kompatibilität.

Wie lange dauert die Unterbrechung bei einem Upgrade mit pg_upgrade?

Eine seriöse feste Dauer lässt sich ohne Datenbankgröße, Hardware, Erweiterungen, Dateisystem und geplante Prüfungen nicht angeben. Führen Sie pg_upgrade zunächst mit einer Kopie der Produktionsdaten aus und messen Sie den gesamten Ablauf einschließlich Vorprüfungen, Umschaltung und Anwendungstests. Die gemessene Dauer ist dann die Grundlage für das Wartungsfenster; planen Sie außerdem einen getesteten Rückfall ein, falls die Abnahme scheitert.

Wenn die Zielversion feststeht, sollte zuerst die Generalprobe samt Wiederherstellung abgeschlossen werden; erst danach ist ein Produktionsfenster belastbar. Bei einer Migration auf eigene Hardware sind direkte NVMe-Laufwerke und ausreichend Arbeitsspeicher nur dann ein Vorteil, wenn Ausfallschutz und externe Sicherungen mitgeplant sind. Für dauerhaft betriebene Datenbanken kann ein dedizierter CloudUDP-Server daher besser passen als eine gemeinsam genutzte Umgebung, in der Ressourcenzuteilung, Speicheroptionen oder langfristige Kosten nicht zum eigenen Lastprofil passen. Wer dagegen nur kurzzeitig testet, sehr geringe Last hat oder elastische Abrechnung benötigt, sollte nicht allein wegen des PostgreSQL-Upgrades auf eine physische Maschine wechseln. Die Zielkonfiguration lässt sich anhand der tatsächlich verfügbaren Optionen prüfen, bevor eine Migration geplant wird.

Häufig gestellte Fragen