PostgreSQL 14 Supportende am 12. November 2026: Upgrade auf 18 oder 19

PostgreSQL 14 im Einsatz? WZ-IT plant und führt Major-Upgrades von PostgreSQL durch und betreibt die Datenbank anschließend mit Monitoring, Backups und Restore-Tests, siehe PostgreSQL bei WZ-IT und Managed Operations. Termin vereinbaren

Am 12. November 2026 erscheint das letzte Minor-Release für PostgreSQL 14. Danach gibt es für diese Major-Version keine Fehler- und Sicherheitskorrekturen mehr. Die PostgreSQL Global Development Group hat das in der Ankündigung vom 13. August 2026 noch einmal ausdrücklich formuliert: Wer PostgreSQL 14 produktiv betreibt, sollte ein Upgrade auf eine unterstützte Version planen (Release-Ankündigung).

Gleichzeitig steht PostgreSQL 19 kurz vor der Veröffentlichung, angekündigt für Oktober 2026. Damit stellt sich die Frage nach der Zielversion neu: das seit einem Jahr verfügbare PostgreSQL 18 oder direkt die neue Version 19. Dieser Beitrag zeigt die offiziellen Supportzeiträume, ordnet die Zielversionen ein, vergleicht die drei Upgrade-Wege und listet die Inkompatibilitäten, die beim Sprung von 14 auf 18 relevant sind. Alle Versionsangaben haben den Stand Oktober 2026.

Inhaltsverzeichnis

1. Was das Supportende von PostgreSQL 14 bedeutet
2. Supportzeiträume aller PostgreSQL-Versionen
3. Zielversion: PostgreSQL 17, 18 oder 19
4. PostgreSQL 19 vor dem Release
5. Drei Upgrade-Wege im Vergleich
6. In-Place-Upgrade von 14 auf 18
7. Upgrade über logische Replikation
8. Inkompatibilitäten zwischen Version 14 und 18
9. Checkliste vor dem Upgrade
10. Unser Vorgehen bei WZ-IT
11. Weiterführende Guides

Was das Supportende von PostgreSQL 14 bedeutet

PostgreSQL unterstützt jede Major-Version fünf Jahre lang ab der Erstveröffentlichung. Danach folgt ein letztes Minor-Release, anschließend gilt die Version als End-of-Life (Versioning Policy). PostgreSQL 14 erschien am 30. September 2021, das letzte Release ist für den 12. November 2026 angesetzt, zeitgleich mit dem regulären Minor-Release-Termin im Release-Kalender.

Der Betrieb bricht am Stichtag nicht ab. Das Risiko liegt in den Lücken, die danach bekannt werden. Wie viel in einem Quartal zusammenkommt, zeigt das Release vom 13. August 2026: Es behob 28 Sicherheitslücken und mehr als 110 Fehler. Darunter war CVE-2026-16239, eine Type Confusion im Lebenszyklus von Cursorn, über die ein angemeldeter Datenbanknutzer Code als Betriebssystemnutzer des Datenbankservers ausführen kann (CVSS 8.8). Sie betraf alle Versionen von 14 bis 18 und ist in 14.24 behoben. Für eine vergleichbare Lücke nach dem 12. November 2026 gäbe es für PostgreSQL 14 keinen Patch mehr.

Für Unternehmen im Geltungsbereich von NIS2 oder mit ISO-27001-Zertifizierung kommt hinzu, dass nicht mehr gepflegte Software in Audits regelmäßig als Befund auftaucht. Wie sich Versionsstände und Schwachstellen systematisch verfolgen lassen, beschreibt der Beitrag zum CVE-Monitoring für Self-Hosted-Software.

Distributionspakete. Ubuntu 22.04 LTS liefert im Paket postgresql die Version 14 aus (packages.ubuntu.com). Ob und wie lange ein Distributor nach dem Ende des Upstream-Supports Korrekturen zurückportiert, regelt dessen eigener Lebenszyklus, nicht die PostgreSQL-Community. Neuere Major-Versionen für Debian und Ubuntu stellt das Community-Repository apt.postgresql.org bereit.

Supportzeiträume aller PostgreSQL-Versionen

Quelle: PostgreSQL Versioning Policy, Stand Oktober 2026. Minor-Releases erscheinen mindestens einmal pro Quartal; die nächsten Termine sind laut Release-Kalender der 12. November 2026, der 11. Februar 2027, der 13. Mai 2027 und der 12. August 2027. Die Community empfiehlt, immer das aktuelle Minor-Release der eingesetzten Major-Version zu betreiben.

Wer von 14 auf 15 oder 16 aktualisiert, steht in ein bis zwei Jahren erneut vor einem Major-Upgrade. PostgreSQL 15 endet im November 2027, 16 im November 2028. Das spricht dafür, beim Wechsel mindestens auf 17 zu gehen.

Zielversion: PostgreSQL 17, 18 oder 19

PostgreSQL 18 ist für die meisten Systeme, die jetzt von 14 wechseln müssen, das naheliegende Ziel. Die Version läuft seit September 2025, hat sechs Minor-Releases hinter sich und wird bis November 2030 unterstützt. Für den Upgrade-Vorgang selbst bringt sie zwei konkrete Vorteile (Release-Ankündigung PostgreSQL 18): pg_upgrade übernimmt die meisten Planer-Statistiken, wodurch das System nach der Umstellung schneller die gewohnte Abfrageleistung erreicht, und der neue Modus --swap verschiebt die Datenverzeichnisse, statt Dateien zu kopieren oder zu verlinken. Daneben kamen ein neues asynchrones I/O-Subsystem, Skip Scan auf mehrspaltigen B-Tree-Indizes, uuidv7() und OAuth-Authentifizierung hinzu.

PostgreSQL 17 kommt infrage, wenn ein Anwendungshersteller oder eine Erweiterung PostgreSQL 18 noch nicht freigegeben hat. Mit Support bis November 2029 bleibt ausreichend Abstand zum nächsten Pflicht-Upgrade.

PostgreSQL 19 ist für den Oktober 2026 angekündigt. Für ein Upgrade, das bis zum 12. November 2026 abgeschlossen sein soll, ist das ein knappes Fenster: Zwischen Release und Stichtag blieben wenige Wochen für Tests, und Erweiterungen wie PostGIS oder TimescaleDB brauchen erfahrungsgemäß eine Weile, bis passende Pakete vorliegen. Wer 14 bis zum Stichtag ablösen muss, wechselt deshalb auf 18 und plant 19 als späteres, reguläres Upgrade ein.

PostgreSQL 19 vor dem Release

Die Release Notes zu PostgreSQL 19 führen Stand Ende September 2026 noch kein Veröffentlichungsdatum. Laut Ankündigung von Beta 4 ist ein Release Candidate für Anfang Oktober geplant, die allgemeine Verfügbarkeit für Oktober 2026 (Beta 4).

Quelle: Release Notes PostgreSQL 19, Stand Beta 4.

Zurückgenommen mit Beta 4. Einige Funktionen, die in früheren Betas enthalten waren und in vielen Vorschauen genannt werden, sind nicht mehr Teil von PostgreSQL 19: SQL/PGQ für Property-Graph-Abfragen, das Ein- und Ausschalten von Data Checksums im laufenden Betrieb, temporale Updates und Deletes mit FOR PORTION OF, ALTER TABLE ... MERGE PARTITIONS und SPLIT PARTITIONS sowie die Funktionen pg_get_role_ddl(), pg_get_tablespace_ddl() und pg_get_database_ddl(). Begründet wird das mit Zuverlässigkeit und dem Ziel, den Release-Termin zu halten.

Inkompatibilitäten in 19. Die Release Notes nennen unter anderem: RADIUS-Authentifizierung entfällt, standard_conforming_strings lässt sich nicht mehr ausschalten, JIT ist standardmäßig deaktiviert, max_locks_per_transaction steigt von 64 auf 128, und die Kodierung MULE_INTERNAL wird nicht mehr unterstützt. Auch diese Punkte sind Stand Beta 4 und können sich bis zum Release noch ändern.

Drei Upgrade-Wege im Vergleich

Ein Major-Upgrade ändert das interne Speicherformat. Ein einfacher Paketwechsel wie bei Minor-Updates reicht nicht. Die PostgreSQL-Dokumentation beschreibt drei Wege (Upgrading a PostgreSQL Cluster):

Für den Dump empfiehlt die Dokumentation, pg_dump und pg_dumpall der neueren Version zu verwenden. Unabhängig vom Weg gilt: ein aktuelles, getestetes Backup vor dem Upgrade, und der Abschnitt "Migration" in den Release Notes jeder übersprungenen Version.

In-Place-Upgrade von 14 auf 18

pg_upgrade unterstützt Upgrades ab Version 9.2 direkt auf die aktuelle Major-Version (pg_upgrade). Ein Zwischenschritt über 15, 16 oder 17 ist nicht nötig. Der Ablauf in Kurzform:

1. Pakete für PostgreSQL 18 parallel zu 14 installieren, inklusive aller Erweiterungen in Versionen für 18.
2. Neuen Cluster mit initdb anlegen, mit denselben Einstellungen für Kodierung, Locale und Data Checksums.
3. pg_upgrade --check ausführen. Die Prüfung läuft auch, während der alte Server noch in Betrieb ist.
4. Alten Server stoppen, pg_upgrade mit dem gewählten Transfermodus ausführen.
5. Konfiguration (postgresql.conf, pg_hba.conf) übertragen und prüfen, neuen Server starten.
6. Fehlende Statistiken erzeugen: vacuumdb --all --analyze-in-stages --missing-stats-only, danach vacuumdb --all --analyze-only.

Transfermodi. Der Standard --copy kopiert alle Datendateien. --clone und --copy-file-range nutzen effizientere Kopierverfahren des Dateisystems. --link arbeitet mit Hardlinks und ist deutlich schneller, der alte Cluster ist aber nicht mehr nutzbar, sobald der neue gestartet wurde. Der in 18 neue Modus --swap verschiebt die Datenverzeichnisse; ab Beginn des Dateitransfers wird der alte Cluster verändert und darf nicht mehr gestartet werden. Bei Link und Swap ist ein Rückweg nur über ein Backup möglich.

Data Checksums. Ab PostgreSQL 18 aktiviert initdb Prüfsummen auf Datenseiten standardmäßig. pg_upgrade verlangt, dass alter und neuer Cluster dieselbe Einstellung haben (Release Notes 18, Migration). Viele PostgreSQL-14-Cluster laufen ohne Prüfsummen. Zwei Lösungen: Den neuen Cluster mit initdb --no-data-checksums anlegen, oder die Prüfsummen vorher im gestoppten alten Cluster mit pg_checksums aktivieren. pg_checksums setzt einen sauber gestoppten Server voraus und schreibt die betroffenen Blöcke neu; bei großen Datenbanken kann das laut Dokumentation lange dauern.

Streaming-Replikation. Physische Standbys lassen sich nicht über Major-Versionen hinweg betreiben. Nach dem Upgrade des Primärservers werden Standbys entweder neu aufgebaut oder, wenn pg_upgrade im Link-Modus lief, nach dem in der pg_upgrade-Dokumentation beschriebenen rsync-Verfahren aktualisiert. Hochverfügbarkeits-Setups mit Patroni oder repmgr brauchen dafür einen eigenen, vorab getesteten Ablauf.

Statistiken. pg_upgrade in Version 18 übernimmt die meisten Planer-Statistiken. Nicht übertragen werden mit CREATE STATISTICS angelegte erweiterte Statistiken, Statistiken von Erweiterungen und die kumulativen Statistiken (pg_stat_*). Ohne die Nacharbeit mit vacuumdb können einzelne Abfragen nach dem Upgrade schlechtere Pläne bekommen.

Upgrade über logische Replikation

Die logische Replikation funktioniert zwischen unterschiedlichen Major-Versionen. Damit lässt sich ein neuer Server mit PostgreSQL 18 als Abonnent eines PostgreSQL-14-Servers aufbauen, im laufenden Betrieb synchronisieren und zu einem festgelegten Zeitpunkt umschalten. Die Unterbrechung beschränkt sich laut Dokumentation auf wenige Sekunden (Upgrading via Replication).

Die Einschränkungen der logischen Replikation gelten auch für diesen Weg (Restrictions):

Die Replikation von Sequenzen, die PostgreSQL 19 mitbringt, hilft bei einem Upgrade von 14 nicht, weil die Quelle die Funktion nicht kennt. Die Umschaltung selbst umfasst: Schreibzugriffe auf der Quelle anhalten, Replikationsrückstand abwarten, Sequenzen setzen, Anwendung auf den neuen Server umstellen. Ein Rückweg bleibt möglich, solange auf dem alten Server keine Daten verloren gehen; für einen Rückweg nach Schreibzugriffen auf dem neuen Server braucht es eine Replikation in Gegenrichtung.

Dieser Weg eignet sich auch, wenn mit dem Upgrade gleichzeitig der Server oder der Standort wechselt, etwa von einem Managed-Datenbankdienst eines Hyperscalers auf eigene Infrastruktur. Wie das mit Dump und Restore abläuft, zeigen die Guides zur Migration von AWS RDS und Azure Database for PostgreSQL.

Inkompatibilitäten zwischen Version 14 und 18

Beim Sprung von 14 auf 18 gelten die Migrationshinweise der Versionen 15, 16, 17 und 18 gemeinsam. Eine Auswahl der Punkte, die in der Praxis häufig auffallen:

Quellen: Migrationsabschnitte der Release Notes 15 und Release Notes 18. Die Tabelle ersetzt nicht das Lesen der Release Notes 16 und 17, die weitere Änderungen an Funktionen, Systemkatalogen und Konfigurationsparametern enthalten.

Die MD5-Abkündigung verdient besondere Aufmerksamkeit. PostgreSQL 19 gibt nach einer erfolgreichen MD5-Anmeldung bereits eine Warnung aus, die Entfernung ist für eine künftige Version angekündigt. Wer ohnehin ein Upgrade durchführt, stellt Passwörter am besten im selben Zug auf SCRAM-SHA-256 um.

Checkliste vor dem Upgrade

Ein Testlauf an einer Kopie ist der wichtigste Punkt. Er zeigt die tatsächliche Laufzeit, fehlende Erweiterungspakete und Fehler aus pg_upgrade --check, bevor das produktive Wartungsfenster beginnt.

Unser Vorgehen bei WZ-IT

1. Bestandsaufnahme. Alle PostgreSQL-Instanzen mit Version, Erweiterungen, Replikation, Backup-Verfahren und abhängigen Anwendungen.
2. Zielversion und Weg. Festlegung von Zielversion (in der Regel 18, bei fehlender Freigabe 17) und Upgrade-Methode nach Datenmenge, zulässiger Ausfallzeit und Infrastruktur.
3. Testlauf. Upgrade an einer Kopie der Produktivdaten, Messung der Laufzeit, Abstimmung der Tests mit den Anwendungsverantwortlichen.
4. Durchführung. Upgrade im vereinbarten Wartungsfenster mit dokumentiertem Rückfallplan, anschließend Statistiken, Prüfung der Anwendungen und Monitoring.
5. Betrieb. Auf Wunsch übernimmt WZ-IT den laufenden Betrieb von PostgreSQL mit Monitoring, Backups, Restore-Tests und regelmäßigen Minor-Updates, eingebettet in Managed Operations und das CVE-Monitoring.

Die Upgrades führen wir auf Ihrer eigenen Infrastruktur, on-premise oder auf Servern in deutschen Rechenzentren durch. Wenn mit dem Upgrade auch ein Umzug aus einem Hyperscaler ansteht, verbinden wir beides mit einem Vorgehen aus dem Bereich Migration.

Weiterführende Guides

• AWS RDS und Aurora PostgreSQL zu Hetzner migrieren, Migration mit pg_dump und pg_restore Schritt für Schritt.
• Azure Database for PostgreSQL zu Hetzner migrieren, Ablauf und Fallstricke beim Wechsel aus Azure.
• MySQL, MariaDB und Percona im Vergleich, die MySQL-Familie und die Abgrenzung zu PostgreSQL.
• CVE-Monitoring für Self-Hosted-Software, Schwachstellen und Versionsstände systematisch verfolgen.
• PostgreSQL bei WZ-IT, Installation, Betrieb, Replikation und Backups.

PostgreSQL 14 vor dem 12. November ablösen Wir prüfen Ihre Instanzen, testen das Upgrade an einer Kopie und führen die Umstellung auf PostgreSQL 18 im abgestimmten Wartungsfenster durch. Termin vereinbaren

Quellen

• PostgreSQL, Versioning Policy
• PostgreSQL, Release-Kalender (Roadmap)
• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 und 19 Beta 3, Release-Ankündigung vom 13.08.2026
• PostgreSQL, CVE-2026-16239
• PostgreSQL 19 Beta 4, Ankündigung vom 24.09.2026
• PostgreSQL 19, Release Notes
• PostgreSQL 18, Release-Ankündigung
• PostgreSQL 18, Release Notes
• PostgreSQL 15, Release Notes
• PostgreSQL 18, Upgrading a PostgreSQL Cluster
• PostgreSQL 18, pg_upgrade
• PostgreSQL 18, pg_checksums
• PostgreSQL 18, Logical Replication Restrictions
• PostgreSQL Wiki, Apt-Repository
• Ubuntu Packages, postgresql in Jammy (22.04)