Wichtigste Erkenntnisse

•   PostgreSQL 12 erreichte am 14. November 2024 das Ende seines Lebenszyklus, und eine Woche später wurde die letzte Community-Version, 12.22, veröffentlicht – es gibt keine weiteren Sicherheitspatches oder Fehlerbehebungen mehr seitens der Community.
•   Die Datenbank läuft auch nach Ablauf der Lebensdauer (EOL) weiter, und genau darin liegt das Problem: Ungepatchte CVEs häufen sich unbemerkt an, bis eine Compliance-Prüfung oder ein Exploit die Situation dringlich macht.
•   Ihre realistischen Optionen sind entweder ein Upgrade auf eine unterstützte Version (18, 17, 16 oder 15) oder die Inanspruchnahme des vom Hersteller angebotenen oder vom Cloud-Anbieter erweiterten Supports, um während der Planung der Migration weiterhin mit den neuesten Patches versorgt zu bleiben.
•   Umfangreiche PostgreSQL-Upgrades erfordern viel Zeit für Tests – Kompatibilitätsprobleme im Zusammenhang mit Erweiterungen und Treibern verursachen in der Regel mehr Aufwand als die Umstellung selbst.

Ihre PostgreSQL-12-Instanz ist am 15. November 2024 nicht abgestürzt. Wahrscheinlich gab es nicht einmal eine kleine Störung. Und genau darin liegt die Falle.

PostgreSQL 12 hat am 14. November 2024 das Ende der Lebensdauer erreicht. Die Community hat eine letzte außerplanmäßige Version, 12.22, um einen Regressionsfehler zu beheben – und schloss den Zweig dann endgültig. Die Software läuft zwar noch, Sicherheits- und Fehlerbehebungen gibt es jedoch nicht mehr. Die meisten Teams lassen sie stillschweigend in der Produktion und widmen sich dringenderen Aufgaben. Monate später stellt sich dann heraus, dass eine neu bekannt gewordene Sicherheitslücke die 12.x-Reihe betrifft, ein Patch von der Community wird nicht mehr veröffentlicht, und ein System, das „einwandfrei funktionierte“, weist plötzlich eine bekannte, nicht behebbare Schwachstelle auf.

Dieser Leitfaden erläutert, was sich an diesem EOL-Stichtag tatsächlich geändert hat, wie die tatsächlichen Risiken in der Praxis aussehen und welche Möglichkeiten Sie haben, um wieder einen gepatchten Zustand zu erreichen – einschließlich ehrlicher Hinweise darauf, wo die einzelnen Wege ihre Tücken haben.

Was bedeutet das Ende des Supportzyklus für PostgreSQL 12?

„End of Life“ bedeutet, dass die PostgreSQL Global Development Group die letzte Version der 12.x-Reihe veröffentlicht und den Zweig geschlossen hat. Es gibt keine Sicherheitspatches mehr und keine Fehlerbehebungen. Wenn eine neu bekannt gewordene Sicherheitslücke PostgreSQL 12 betrifft, bleibt sie auf Community-Ebene dauerhaft ungepatcht. Eine EOL-Datenbank, die regulierte Daten verarbeitet oder eine mit dem Internet verbundene Anwendung unterstützt, wird jedes Mal zu einem wachsenden Risiko, wenn eine neue Sicherheitslücke in ihrem Zweig auftaucht, da keine Community-Korrektur mehr erfolgt.

Wichtige EOL-Termine für PostgreSQL, die Sie beachten sollten

Das PostgreSQL-Projekt unterstützt jede Hauptversion fünf Jahre lang ab der ersten Veröffentlichung, veröffentlicht anschließend noch eine letzte Nebenversion und betrachtet das Projekt dann als abgeschlossen. Es gibt keine getrennten „aktiven“ und „Wartungs“-Stufen wie bei Node.js LTS. Es handelt sich um einen einzigen Fünfjahreszeitraum, danach wird der Zweig eingestellt.

Version	Veröffentlicht	Ende des Lebens	Status
18	September 2025	Nov. 2030	Unterstützt (aktuellste Version)
17	September 2024	Nov. 2029	Unterstützt
16	September 2023	Nov. 2028	Unterstützt
15	Okt. 2022	Nov. 2027	Unterstützt
14	September 2021	Nov. 2026	Unterstützt (endet bald)
13	September 2020	Nov. 2025	EOL
12	Okt. 2019	Nov. 2024	EOL
11	Okt. 2018	Nov. 2023	EOL

Wenn Sie Version 12 verwenden, liegen Sie zwei Hauptversionen hinter dem ältesten unterstützten Zweig zurück. Wenn Sie Version 13 verwenden, sind seit November 2025 . Version 14 sieht auf dem Papier sicher aus, aber ihr EOL-Termin ist der 12. November 2026 – näher als den meisten Menschen bewusst ist.

Warum PostgreSQL-Versionen aus dem Verkehr gezogen werden

Die Einstellung einer Hauptversion bedeutet nicht, dass die Community Schwierigkeiten macht. Es handelt sich um einen bewussten Kompromiss, der die Gesundheit des Projekts gewährleistet. Dahinter stehen mehrere Faktoren.

Die Fünfjahresfrist ist bewusst so festgelegt

PostgreSQL garantiert fünf Jahre Support für jede Hauptversion, gerechnet ab der Erstveröffentlichung. Diese Vorhersehbarkeit ist wirklich nützlich: Man kann sich jede beliebige Version ansehen und ihr Ablaufdatum schon Jahre im Voraus kennen.

Der Haken daran ist, dass die Uhr sich nicht um Ihren Migrationsrückstand schert. PostgreSQL 12 wurde im Oktober 2019 veröffentlicht, sodass das Ende der Lebensdauer (EOL) im November 2024 praktisch vom ersten Tag an feststand. Teams, die dieses Datum als „irgendwann“ betrachteten, mussten feststellen, dass es – wie es bei Terminen nun einmal so ist – pünktlich eintraf.

Die Pflege alter Zweige wird kostspielig

Jede unterstützte Hauptversion ist ein eigener Zweig, den die Betreuer mit Patches versehen, testen und veröffentlichen müssen. Das Backportieren eines einzigen Sicherheitspatches auf fünf oder sechs aktive Zweige ist echte technische Arbeit, die von den Projektmitarbeitern und den Unternehmen, die diese unterstützen, geleistet wird.

Irgendwann übersteigen die Kosten für die Aufrechterhaltung eines alten Zweigs den Nutzen. Die Codepfade divergieren. Die Testinfrastruktur veraltet. Eine Korrektur, die im aktuellen Zweig unkompliziert ist, erfordert möglicherweise umständliche Eingriffe in eine fünf Jahre alte Codebasis. Durch die Stilllegung des ältesten Zweigs kann das Projekt diese Energie auf die Versionen konzentrieren, die tatsächlich von den meisten Nutzern verwendet werden.

Sicherheits-Backports haben eine begrenzte Lebensdauer

Manche Sicherheitslücken lassen sich in altem Code leicht beheben. Andere hängen von der Architektur ab, die in neueren Versionen geändert wurde, und das Zurückportieren dieser Korrekturen in einen deutlich älteren Zweig kann von mühsam bis hin zu regelrecht riskant reichen. Das Zurückportieren selbst könnte Regressionen in Codepfaden verursachen, die seit Jahren nicht mehr genutzt wurden.

Sobald eine Version das Ende ihrer Lebensdauer (EOL) erreicht hat, liegt die Last des Backportings bei Ihnen oder bei demjenigen, den Sie dafür bezahlen.

Risiken beim Betrieb einer PostgreSQL-Version am Ende ihres Lebenszyklus (EOL)

Die Risiken eines Verbleibs bei PostgreSQL 12 sind nicht nur hypothetisch. Je länger Sie warten, desto größer werden sie.

Ungepatchte Sicherheitsschwachstellen

Jede Sicherheitslücke, die nach dem EOL von PostgreSQL 12 bekannt wird, bleibt auf Community-Ebene unbehoben, Punkt. Die außerplanmäßige Version 12.22 vom 21. November 2024 war die letzte Patch-Version, die die Version 12 jemals erhalten wird – sie wurde veröffentlicht, um einen Regressionsfehler in 12.21 zu beheben, nicht um den Support zu verlängern. Alles, was danach bekannt wird, betrifft entweder Version 12 nicht oder betrifft sie zwar, wird aber niemals durch die Community behoben werden.

Der allgemeine Trend verschlimmert die Situation noch. Sicherheitslücken-Tracker verzeichneten in der ersten Hälfte des Jahres 2026 16 PostgreSQL-CVEs – bereits mehr als im gesamten Jahr 2025 – mit einem durchschnittlichen Schweregrad von über 7. Das Sicherheitsrelease vom Mai 2026 allein wurden 11 Sicherheitslücken in den unterstützten Zweigen behoben, deren Schweregrad bis zu 8,8 betrug. Nicht alle davon betreffen Version 12. Die Sorge ist, was passiert, wenn ein neu bekannt gewordener Fehler diese Version betrifft: Die Community stellt dafür keinen Fix mehr bereit.

Weitere Informationen zum Schutz Ihrer Umgebung vor Risiken durch nicht gepatchte Sicherheitslücken finden Sie in unserem ausführlichen Leitfaden zu den bewährten Verfahren für die PostgreSQL-Sicherheit. Außerdem können Sie sich in unserem ausführlichen Leitfaden über PostgreSQL-Sicherheitslücken und die damit verbundenen Sicherheitsrisiken informieren.

Genau diese Lücke soll durch den vom Hersteller unterstützten erweiterten Support geschlossen werden. Mehr dazu im Abschnitt „Optionen“ weiter unten.

Versäumnisse bei Compliance und Audit

PCI DSS schreibt ausdrücklich vor, bekannte Sicherheitslücken zu beheben und Technologien, deren Lebensdauer abgelaufen ist, im Geltungsbereich zu überwachen. HIPAA und SOC 2 erwähnen EOL-Software zwar nicht ausdrücklich, doch Prüfer betrachten eine Datenbank, für die keine Sicherheitspatches mehr bereitgestellt werden, als ein potenzielles Problem. In jedem Fall ist die Aussage „Der Anbieter stellt keine Patches mehr bereit“ schwer zu verteidigen, ganz gleich, wie gut der Rest Ihrer Infrastruktur abgesichert ist.

Prüfer überprüfen den Status der Versionsunterstützung direkt – mithilfe von Fragebögen, Schwachstellenscans und Bestandsaufnahmen. „Wir arbeiten gerade an der Aktualisierung“ ist keine überzeugende Antwort, wenn das EOL-Datum bereits im November 2024 abgelaufen ist. Die Feststellungen haben konkrete Kosten zur Folge: entgangene Geschäfte, Fristen für Abhilfemaßnahmen und in regulierten Branchen Geldstrafen.

Veränderung des Ökosystems

Die Sicherheit steht zwar im Mittelpunkt der Aufmerksamkeit, doch das schleichende Problem ist, dass sich alles rund um die Datenbank von Version 12 wegbewegt. Die Betreuer von Erweiterungen stellen die Tests für diese Version ein. Client-Treiber stellen die Unterstützung ein. Managed Provider erheben Zuschläge für erweiterten Support, blockieren neue Bereitstellungen oder planen erzwungene Upgrades.

Für sich genommen ist nichts davon katastrophal, aber es summiert sich. Irgendwann veröffentlicht ein Bibliotheksbetreuer eine Version, die das Verhalten von PostgreSQL 14+ voraussetzt, oder Ihre Überwachungsintegration stellt die Unterstützung für 12.x ein. Am Ende haben Sie eine Datenbank, an der Sie nicht mehr sicher etwas ändern können und die Sie nicht ohne Weiteres aufgeben können.

Möglichkeiten nach Ablauf der Lebensdauer von PostgreSQL 12

Sie haben vier realistische Optionen. Die richtige Entscheidung hängt von Ihrer Risikobereitschaft ab: Können Sie die mit einem Upgrade verbundenen Beeinträchtigungen derzeit verkraften, oder müssen Sie die aktuellen Patches beibehalten und die Compliance-Anforderungen erfüllen, während Sie einen stabilen Migrationsplan ausarbeiten?

1. Vom Hersteller angebotener erweiterter Support

Wenn Sie nicht sofort migrieren können, aber auch nicht auf ungepatchter Software sitzen bleiben wollen, ist der erweiterte Support die ideale Übergangslösung. Einige Anbieter bieten dies an. Der „Endless Lifecycle Support“ von TuxCare umfasst derzeit PostgreSQL 13, und das Unternehmen hat angekündigt, Version 14 noch vor deren EOL-Datum hinzuzufügen.

Der Sinn des erweiterten Supports besteht nicht darin, ein Upgrade auf unbestimmte Zeit zu vermeiden. Vielmehr geht es darum, eine feste Frist in ein geplantes Projekt umzuwandeln. Anstelle einer Notfallmigration, die zwischen der Arbeit an neuen Funktionen in einen Sprint gequetscht wird, erhalten Sie eine gepatchte Instanz und den nötigen Spielraum, um die Migration dann durchzuführen, wenn Sie bereit sind – und nicht erst, wenn eine CVE oder ein Prüfer Sie dazu zwingt.

Diese Option eignet sich für Teams in regulierten Umgebungen, für solche, die stark angepasste Konfigurationen nutzen, oder für alle, deren realistisches Migrationsfenster noch Monate entfernt ist. Außerdem erhalten Sie damit einen dokumentierten Patch-Pfad, den Sie den Prüfern vorlegen können, während das eigentliche Upgrade noch läuft.

2. Upgrade auf PostgreSQL 18

PostgreSQL 18 ist die aktuelle Version, die bis November 2030 unterstützt wird. Wenn Sie direkt darauf umsteigen, haben Sie die längste Zeitspanne, bevor Sie diese Übung erneut durchführen müssen, und profitieren zudem von den neuesten Verbesserungen bei Leistung und Funktionen.

Der Nachteil ist der Umfang: Der Sprung von Version 12 auf 18 umfasst sechs Hauptversionssprünge, was bedeutet, dass mehr Verhaltensänderungen auf einmal überprüft werden müssen – Unterschiede im Planer, veraltete Einstellungen und die Kompatibilität der Erweiterungen auf breiter Front. Verwenden Sie „pg_upgrade“ (wobei die Binärdateien der neuen Version neben den alten installiert werden) anstelle eines vollständigen Dump-and-Restore, aber planen Sie ausreichend Zeit für die Testphase ein:

pg_upgrade \

  –old-datadir /var/lib/postgresql/12/main \

  –new-datadir /var/lib/postgresql/18/main \

  –old-bindir /usr/lib/postgresql/12/bin \

  –new-bindir /usr/lib/postgresql/18/bin \

  –Überprüfen

Die angegebenen Pfade entsprechen den Standardwerten von Debian/Ubuntu – passen Sie diese entsprechend Ihrer Distribution an. Führen Sie das Programm mit –check aus: So werden viele kritische Fehler aufgedeckt, bevor Sie sich festlegen, auch wenn nicht jedes Problem auf Anwendungsebene oder jedes Leistungsproblem erkannt wird.

3. Upgrade auf PostgreSQL 17, 16 oder 15 (wird weiterhin unterstützt)

Falls Ihnen Version 18 als zu großer Sprung erscheint, werden PostgreSQL 17 (EOL November 2029), 16 (EOL November 2028) und 15 (EOL November 2027) weiterhin von der Community unterstützt und entsprechen eher dem Verhalten von Version 12. Viele Teams entscheiden sich bewusst für eine dieser Versionen als Zwischenschritt: Die Supportdauer ist lang genug, um von Bedeutung zu sein, und es gibt weniger Überraschungen als bei der neuesten Version.

Behalten Sie jedoch den Zeitplan im Auge. Wenn Sie sich für 15 im Jahr 2026 entscheiden, haben Sie kaum anderthalb Jahre Zeit, bevor Sie sich wieder mit der EOL-Planung befassen müssen – 17 oder 16 bieten der Zwischenstufenstrategie tatsächlich etwas Spielraum. Die Wahl einer dieser Versionen anstelle von 18 ist sinnvoll, wenn Ihre Erweiterungen noch nicht für die neueste Version zertifiziert sind oder wenn Sie eine Version mit einer längeren Produktionshistorie bevorzugen.

Profi-Tipp: Führen Sie SELECT * FROM pg_extension; auf Ihrer Live-Instanz der Version 12.x aus, bevor Sie ein Ziel auswählen, und überprüfen Sie anschließend jede Erweiterung hinsichtlich der Zielversion. Meistens sind es die Erweiterungen und nicht der PostgreSQL-Kern, die Upgrades mitten im Projekt zum Stillstand bringen.

4. Erweiterter Support für Managed Cloud

Wenn Sie Amazon RDS, Google Cloud SQL oder eine berechtigte Azure Database for PostgreSQL-Bereitstellung nutzen, bietet Ihr Anbieter möglicherweise kostenpflichtigen erweiterten Support für bestimmte EOL-Versionen an – die Verfügbarkeit und die Teilnahmebedingungen variieren je nach Dienst und Version. Amazon RDS hat PostgreSQL 12 nach Ablauf des Standard-Supportzeitraums am 28. Februar 2025 in den RDS-Erweiterten Support übernommen, wobei Zuschläge pro vCPU anfallen. Google Cloud SQL erhebt seit dem 1. Mai 2025 Gebühren für den erweiterten Support von EOL-Hauptversionen. Azure nimmt Server mit nicht mehr unterstützten Versionen nun automatisch in den erweiterten Support auf , wobei die Abrechnung für Version 13 ab dem 1. August 2026 erfolgt.

Dadurch erhalten Sie vom Anbieter verwaltete Sicherheitsupdates, ohne eigene PostgreSQL-Backports pflegen zu müssen, was wirklich nützlich ist. Die Aufschläge steigen jedoch mit der Zeit – die Preise von AWS werden nach den ersten zwei Jahren erhöht –, betrachten Sie dies also als begrenzte Übergangsphase und nicht als langfristige Strategie. Lesen Sie die Preisgestaltung pro Instanz sorgfältig durch, bevor Sie davon ausgehen, dass dies die günstigste Option ist.

Hier ist die Entscheidung auf einen Blick:

Wenn Ihre Situation wie folgt ist…	Der beste Schachzug
Eine Migration ist derzeit nicht möglich, daher müssen wir auf dem neuesten Stand bleiben und die Vorschriften einhalten	Vom Anbieter unterstützter erweiterter Support (z. B. „Endless Lifecycle Support“ von TuxCare)
Bereit für die Migration, möchten die längste Support-Laufzeit	Auf PostgreSQL 18 aktualisieren
Bereit für die Migration, möchten weniger Überraschungen	Auf Version 17 oder 16 aktualisieren
Managed Cloud: Sich kurzfristig Luft verschaffen	Erweiterter Support durch den Anbieter

Die Migration planen, bevor es dringend wird

Die Teams, die gut mit dem EOL umgehen, behandeln ihn wie jedes andere geplante Projekt. Diejenigen, die damit Schwierigkeiten haben, neigen dazu, das EOL-Datum als den Zeitpunkt zu betrachten, ab dem sie anfangen müssen, darüber nachzudenken – was etwa ein Jahr zu spät ist.

Ein praktikabler Migrationsplan umfasst in der Regel:

•   Bestand. Jede 12.x-Instanz, einschließlich der vergessenen Replik und der Analytics-Box, für die niemand verantwortlich ist.
•   Abhängigkeitsprüfung. Erweiterungen, Client-Treiber, ORMs und Replikationswerkzeuge werden jeweils anhand Ihrer Zielversion überprüft.
•   Eine Entscheidung bezüglich der Zielversion. Die Wahl erfolgte aufgrund der Kompatibilität mit Erweiterungen und der weiteren Support-Dauer, nicht aufgrund eines Bauchgefühls.
•   Ein bewährter Upgrade-Pfad. pg_upgrade oder logische Replikation für nahezu unterbrechungsfreie Umstellung, die zunächst in der Staging-Umgebung getestet wird, bevor Sie die Produktionsumgebung berühren.
•   Eine Übergangslösung. So sorgen Sie bis zum Tag der Migration für Sicherheit. Oft bedeutet dies einen erweiterten Support durch den Anbieter oder die Cloud; dokumentierte Ausgleichskontrollen sind die weniger wirksame Alternative.
•   Ein Rollback-Plan. Denn es wird immer etwas Unvorhergesehenes passieren, und Sie wollen einen Ausweg, der nicht nur darin besteht, „die Sicherung von gestern Abend wiederherzustellen“.

Realitätscheck: Anbieter bezeichnen größere Upgrades gerne als „problemlos“. Das sind sie jedoch nicht. Selbst nach einem reibungslosen pg_upgrade-Durchlauf müssen Sie Erweiterungen erneut validieren, Konfigurationen neu anpassen und beobachten, wie sich Abfragepläne verändern. Für eine Produktionsumgebung mit wesentlichen Abhängigkeiten sollten Sie mehrere Wochen für Tests einplanen, nicht nur ein Wartungsfenster.

Was tun, wenn PostgreSQL 12 noch im Produktivbetrieb eingesetzt wird?

PostgreSQL 12 wird nicht plötzlich nicht mehr funktionieren – und genau deshalb neigt man dazu, das Thema zu ignorieren, bis eine CVE oder ein Audit die Angelegenheit dringlich macht. Das ehrliche Fazit: Entscheiden Sie sich bewusst. Führen Sie ein Upgrade auf eine unterstützte Version durch, wenn ein Wechsel möglich ist. Ist dies nicht der Fall, sorgen Sie für eine lückenlose Patch-Abdeckung, damit aus „noch nicht“ nicht „ein Jahr lang ungeschützt“ wird.

Was den erweiterten Support betrifft, deckt TuxCare deckt derzeit Version 13 ab, falls Sie während der Planung des Upgrades eine kommerzielle Patching-Lösung benötigen; die Unterstützung für Version 14 wurde bereits vor deren EOL angekündigt. Klären Sie die genaue Versionsabdeckung mit dem jeweiligen Anbieter ab, bevor Sie den erweiterten Support als Übergangslösung nutzen.

Beginnen Sie damit, Ihre 12.x-Umgebung zu erfassen: Wie viele Instanzen, welche Erweiterungen, was hängt davon ab? Allein diese Bestandsaufnahme macht in der Regel deutlich, welcher Weg sinnvoll ist. Das schlimmste Szenario ist das, bei dem Sie sich gar nicht entscheiden.

FAQs