PostgreSQL 14 End of Life am 12. November 2026: Ein Upgrade-Plan für kleine Teams

PostgreSQL 14 End of Life ist für den 12. November 2026 angesetzt. Das ist der Termin des letzten Releases, danach stellt die PostgreSQL Global Development Group jegliche Fixes für diese Version ein, Sicherheitsfixes eingeschlossen. Läuft Ihre Anwendung noch auf 14, haben Sie eine feste Frist statt einer vagen, und die Uhr zählt bereits auf wenige Wochen herunter.

Das PostgreSQL-Projekt veröffentlicht seine eigene Versionierungsrichtlinie unter postgresql.org/support/versioning, und es lohnt sich, diese Seite direkt zu prüfen, bevor Sie etwas planen, da sich Release-Termine gelegentlich verschieben und Sie die aktuelle Zahl brauchen, nicht das, was in diesem Beitrag nächstes Jahr noch steht. Aktuell listet sie PostgreSQL 14 mit End of Life am 12. November 2026, fünf Jahre nach dem ersten Release, was dem üblichen Muster des Projekts entspricht, jede Hauptversion fünf Jahre lang zu unterstützen.

Was PostgreSQL 14 End of Life für Ihre Datenbank bedeutet

PostgreSQL veröffentlicht jedes Jahr eine neue Hauptversion und unterstützt jede davon fünf Jahre lang ab dem ersten Release. Innerhalb dieses Fensters erscheinen etwa alle drei Monate Minor-Releases mit Bugfixes und Sicherheitspatches, aber ohne neue Funktionen. Nach Ablauf der fünf Jahre endet das. Es gibt keine weiteren Minor-Releases und keine weiteren Patches mehr, auch nicht für danach entdeckte Schwachstellen.

Das unterscheidet sich von einer bloßen Deprecation-Warnung. Eine im Dezember 2026 gefundene Schwachstelle in PostgreSQL 14 wird in 15, 16, 17 und 18 behoben, in 14 behebt sie niemand mehr. Ist Ihre Datenbank aus dem Internet erreichbar, oder auch nur über Anwendungscode erreichbar, der nicht vertrauenswürdige Eingaben verarbeitet, ist das eine echte Angriffsfläche, keine theoretische.

Prüfen, welche Version Sie einsetzen

Das ist ein einziger Befehl. Verbinden Sie sich mit Ihrer Datenbank und führen Sie aus:

SELECT version();

Oder über die Kommandozeile:

psql -c "SELECT version();"

Wenn Sie nicht sicher sind, wie Sie sich verbinden, fragen Sie die Person, die Ihre Infrastruktur betreut, oder prüfen Sie das Dashboard Ihres Hosting-Anbieters. Die meisten Managed-Database-Dienste (RDS, Cloud SQL, Azure Database for PostgreSQL, DigitalOcean, die Nachfolger von Heroku) zeigen die laufende Version direkt in ihrer Konsole an, und einige davon haben bereits begonnen, Kunden wegen der 14-Frist per E-Mail anzuschreiben.

Lautet die Antwort 14.x, sind Sie betroffen, und der Rest dieses Beitrags richtet sich an Sie. Lautet sie 13 oder älter, sind Sie bereits über das End of Life hinaus und sollten das als dringender behandeln, nicht als weniger dringend. Lautet sie 15 oder neuer, sind Sie vorerst auf der sicheren Seite.

Eine Zielversion wählen: 17 oder 18

Sobald klar ist, dass Sie wechseln müssen, stellt sich die Frage, wohin. PostgreSQL 18 ist Stand Ende 2026 das aktuelle Release, 17 ist die Version davor. Beide sind für ein kleines Team, das Aufwand gegen Zeitgewinn abwägt, ein vernünftiges Ziel.

Der Wechsel auf 17 ist der kleinere Schritt von 14 aus, da er den Änderungen von 18 an I/O und der neuen nativen UUIDv7-Generierung vorausgeht. Wurde Ihre Anwendung oder deren Abhängigkeiten noch nicht gegen 18 getestet, oder möchten Sie lieber jetzt ein Upgrade machen und ein zweites nächstes Jahr, ist 17 die sicherere Wahl. Der direkte Sprung auf 18 verschafft mehr Jahre, bevor Sie das Ganze erneut angehen müssen, und bringt die neueren Funktionen, falls Sie diese nutzen wollen, zum Preis eines etwas weniger erprobten Pfads bei manchen Drittanbieter-Tools. Für die meisten kleinen Anwendungen mit klassischer CRUD-Arbeit ist der praktische Unterschied zwischen beiden Zielversionen gering; die ehrliche Antwort lautet, dass Sie mit beiden von einer nicht mehr unterstützten Version wegkommen, und die Wahl hängt vor allem davon ab, wie aktuell die Unterstützung für 18 bei Ihren Extensions und Ihrem ORM bestätigt ist.

Welche Sie auch wählen, überspringen Sie nicht die Prüfung Ihrer Extensions.

Extension-Prüfung, bevor Sie irgendetwas anfassen

Nutzt Ihre Datenbank pgvector, PostGIS oder eine andere Extension, prüfen Sie deren Kompatibilität mit der Zielversion, bevor Sie beginnen, nicht danach. Beide werden aktiv gepflegt und halten in der Regel mit neuen PostgreSQL-Releases Schritt, aber „in der Regel" ist nicht „immer", und eine Versionsabweichung zwischen PostgreSQL und einer Extension kann von einem fehlgeschlagenen ALTER EXTENSION UPDATE bis zu binärer Inkompatibilität reichen, die stillschweigend falsche Ergebnisse liefert.

Die praktische Prüfung ist kurz: Schauen Sie in die eigenen Release-Notes oder das GitHub-Repository der Extension, finden Sie deren aktuelle Version und bestätigen Sie, dass sie Support für Ihre Zielversion von PostgreSQL ausweist. Haben Sie die Extension über Ihren Paketmanager oder einen Managed-Service installiert, prüfen Sie, welche Version dieser Dienst aktuell für 17 oder 18 bereitstellt, bevor Sie sich auf ein Upgrade-Datum festlegen, da manche Anbieter den Extension-Maintainern um einige Wochen hinterherhinken.

Drei Upgrade-Wege, und was sie an Ausfallzeit kosten

Es gibt keinen einzigen richtigen Weg, PostgreSQL zu aktualisieren. Der richtige Weg für ein kleines Team hängt vor allem davon ab, wie viel Ausfallzeit Sie tolerieren können und wie groß Ihre Datenbank ist.

pg_upgrade ist das Standardwerkzeug dafür und für die meisten kleinen bis mittleren Datenbanken die schnellste Option. Es aktualisiert die Datendateien direkt vor Ort, statt jede Zeile zu exportieren und neu zu laden, und mit der Option --link kann es selbst bei Datenbanken im Bereich von mehreren Dutzend Gigabyte in Minuten abschließen, da es Dateien verlinkt statt kopiert. Der Haken: Es erfordert trotzdem Ausfallzeit. Ihre Anwendung kann während des Upgrades nicht in die Datenbank schreiben, und Sie sollten ein Wartungsfenster einplanen, selbst wenn das Werkzeug selbst schnell ist, da Sie zusätzlich den alten Server stoppen, das Upgrade ausführen, das Ergebnis prüfen und den neuen Server starten müssen. Für eine kleine Anwendung bedeutet das meist ein Fenster im Minutenbereich, nicht Stunden, aber es bleibt ein Fenster, das Ihre Nutzer bemerken.

Dump und Restore mit pg_dump und pg_restore ist konzeptionell am einfachsten und in der Praxis am langsamsten. Sie exportieren die gesamte Datenbank in eine Datei und laden diese dann in eine frisch installierte Version von PostgreSQL. Das funktioniert zuverlässig und liefert eine saubere Kopie zum Testen vor der Umstellung, aber die Dauer von Export und Import skaliert mit der Datenbankgröße, und ab wenigen Gigabyte liegt die Ausfallzeit eher im Stundenbereich als im Minutenbereich. Das ist eine vernünftige Wahl für kleine Datenbanken oder als Rückfalloption, falls pg_upgrade Probleme macht, aber selten die erste Wahl, sobald Ihr Datenbestand eine reale Größe erreicht hat.

Logische Replikation ist der Weg, der nahezu null Ausfallzeit erreicht, zum Preis von mehr Aufwand bei der Einrichtung. Sie stellen einen neuen Server auf der Zielversion bereit, replizieren Daten kontinuierlich dorthin, während der alte Server weiter Traffic bedient, und stellen erst um, sobald der neue Server aufgeholt hat. Die Umstellung selbst erfordert noch eine kurze Pause, um den Traffic umzuleiten und zu bestätigen, dass die letzten Transaktionen repliziert wurden, aber diese Pause liegt im Sekundenbereich, nicht im Minutenbereich. Das ist die richtige Wahl, wenn Ihre Anwendung ein Wartungsfenster wirklich nicht verträgt, bringt aber echte Komplexität mit sich: Sie müssen Sequenzen, Large Objects und etwaige DDL-Änderungen sorgfältig behandeln, und ein Testlauf an einer Kopie der Produktionsdatenbank lohnt sich, bevor Sie es ernst machen.

Für die meisten kleinen Teams mit einer Anwendung, die einen kurzen geplanten Ausfall verträgt, ist pg_upgrade die pragmatische Standardwahl. Heben Sie sich logische Replikation für Fälle auf, in denen ein Wartungsfenster wirklich keine Option ist, und Dump und Restore für Datenbanken, die klein genug sind, dass der langsamere Weg keine Rolle spielt.

Was Managed-Anbieter berechnen, wenn Sie die Frist verpassen

Läuft Ihre Datenbank auf einem Managed-Service wie Amazon RDS, Google Cloud SQL oder Azure Database for PostgreSQL, bedeutet das Verpassen des End-of-Life-Datums nicht, dass Ihre Datenbank aufhört zu funktionieren. Sie wechseln in die Extended-Support-Stufe des Anbieters, die genau für Kunden existiert, die noch nicht aktualisiert haben. AWS etwa berechnet für Datenbanken, die unter RDS Extended Support auf einer nicht mehr unterstützten Hauptversion laufen, eine zusätzliche stündliche Gebühr pro vCPU, zusätzlich zu den normalen Instanzkosten, und diese Gebühr ist bewusst so gestaltet, dass sie weniger attraktiv ist als einfach zu aktualisieren.

Diese Gebühren variieren je Anbieter und ändern sich im Zeitverlauf, prüfen Sie also die aktuelle Preisseite Ihres jeweiligen Anbieters, bevor Sie von einer Zahl ausgehen, aber das Muster ist über alle Anbieter hinweg gleich: Extended Support kostet mehr als aktuell zu bleiben, oft deutlich mehr, und ist als kurze Brücke gedacht, nicht als langfristiger Plan. Läuft Ihre Anwendung aus geschäftlichen Gründen, die sich nicht vermeiden lassen, über den 12. November 2026 hinaus noch auf PostgreSQL 14, planen Sie diesen zusätzlichen Posten ein und setzen Sie sich eine interne Frist, innerhalb einiger Monate davon wegzukommen, nicht einiger Jahre.

Ein Ein-Seiten-Upgrade-Plan für das Management

Brauchen Sie Budget oder ein Wartungsfenster genehmigt, hier die Version, die eine nicht-technische Führungskraft handeln kann, ohne den Rest dieses Beitrags zu lesen:

PostgreSQL 14, auf dem unsere Anwendung läuft, erhält nach dem 12. November 2026 keine Fixes mehr, auch keine Sicherheitsfixes. Wir müssen vor diesem Datum auf eine neuere, unterstützte Version wechseln, oder eine steigende zusätzliche Gebühr unseres Hosting-Anbieters akzeptieren, falls wir die Frist verpassen. Die Arbeit selbst ist ein geplantes Upgrade mit einem kurzen Wartungsfenster, typischerweise Minuten für eine Datenbank unserer Größe, in dem die Anwendung kurz nicht verfügbar ist. Wir testen das Upgrade zuerst an einer Kopie der Datenbank, bestätigen, dass unsere Extensions auf der neuen Version noch funktionieren, und planen die eigentliche Umstellung für eine Zeit mit wenig Traffic. Danach gewinnen wir je nach gewählter Version rund [zwei bis fünf] weitere Jahre Support.

Füllen Sie die Klammer mit dem tatsächlichen Abstand zwischen heute und dem eigenen End-of-Life-Datum Ihrer Zielversion von postgresql.org/support/versioning, und Sie haben etwas Konkretes, das Sie der Person vorlegen können, die das Ausfallfenster absegnet.

Wo das in die laufende Wartung passt

Eine End-of-Life-Frist wie diese kommt nur dann überraschend, wenn niemand Support-Termine routinemäßig verfolgt. Wir haben über eine jährliche Checkliste genau für diese Art von Frist geschrieben, damit PostgreSQL 14 die letzte Version ist, die Ihr Team unvorbereitet trifft, statt die nächste in einer Serie.

Muss das Upgrade selbst ohne ein langes Offline-Fenster für Ihre Anwendung erfolgen, behandelt unser Beitrag zu Datenbankmigrationen in laufenden Systemen die Expand-and-Contract-Muster, die das für Schema-Änderungen neben einem Versions-Upgrade möglich machen.

Möchten Sie lieber, dass jemand anderes Ihre aktuelle Version bestätigt, Ihre Extensions prüft und das Upgrade für Sie durchführt, genau das übernimmt unser Code Readiness Sprint innerhalb von ein bis zwei Wochen, oder wir integrieren es in ein laufendes Wartungsretainer, damit Fristen wie diese erledigt sind, bevor sie dringend werden. Melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, um Ihr konkretes Setup zu besprechen.