2026: Wie prüfen Sie die Erweiterungskompatibilität vor dem Supportende von PostgreSQL 14?

Urteil: Erst prüfen, dann produktiv wechseln

Der offizielle PostgreSQL-Supportplan nennt den 12.11.2026 als Ende der Unterstützung für PostgreSQL 14. Prüfen Sie vor einem Upgrade nicht nur, ob der Zielversion eine Erweiterung mit demselben Namen bekannt ist: Die passenden Erweiterungsdateien müssen in der Zielumgebung vorhanden sein, ein unterstützter Updatepfad muss existieren und die von Ihrer Anwendung verwendeten Funktionen müssen in einer isolierten Umgebung funktionieren. Sind diese Prüfungen nicht abgeschlossen, sollten Sie ein nicht erprobtes Upgrade nicht allein wegen des nahenden Termins in die Produktion übernehmen. Der offizielle Versionsplan ist vor der Umstellung erneut zu kontrollieren.

Für Sie geeignet, wenn Sie PostgreSQL 14 selbst betreiben und Erweiterungsabhängigkeiten vor einem Versionswechsel klären müssen.
Besonders relevant für DBAs, Backend-Teams und Verantwortliche für Datenplattformen, die produktive Funktionen, Migration und Rückfall gemeinsam planen.
Weniger relevant, wenn Sie keine Erweiterungen nutzen und lediglich eine allgemeine Entscheidung zwischen PostgreSQL-Zielversionen suchen.

Zuletzt aktualisiert am 28.10.2026; geprüft anhand der offiziellen PostgreSQL-Supportseite, der Versionsdokumentation und der bereitgestellten PostgreSQL-Unterlagen.

Das Risiko: Name, Installation und Nutzbarkeit sind verschiedene Dinge

Bei einer Erweiterung müssen Sie mehrere Ebenen auseinanderhalten. Ein Eintrag in der Liste installierbarer Erweiterungen belegt zunächst nur, dass PostgreSQL in dieser Umgebung ein passendes Erweiterungspaket kennt. Er beweist weder, dass die Erweiterung in einer konkreten Datenbank installiert ist, noch, dass Ihre Anwendung ihre Funktionen tatsächlich nutzt. Umgekehrt kann eine Funktion bereits in Schemaobjekten, Skripten oder Anwendungscode auftauchen, obwohl ein kurzer Blick auf die installierten Erweiterungen diesen Zusammenhang nicht sichtbar macht.

Auch ein gleicher Erweiterungsname auf beiden Servern ist kein Kompatibilitätsnachweis. PostgreSQL-Erweiterungen bestehen aus versionsabhängigen Steuerungs- und Skriptdateien; je nach Erweiterung können zusätzlich Bibliotheken oder andere Systempakete erforderlich sein. Die Dokumentation zum Erweiterungsmechanismus beschreibt, wie Erweiterungen installiert und aktualisiert werden. Daraus folgt für Ihren Wechsel: Sie müssen die Zielumgebung selbst prüfen, statt aus dem Namen allein auf die Verfügbarkeit zu schließen.

Drei typische Kosten- und Stabilitätsfallen entstehen bereits in der Vorplanung:

• Unvollständiges Inventar: pg_extension zeigt installierte Erweiterungen pro Datenbank, aber nicht automatisch sämtliche indirekten Abhängigkeiten in Anwendungen, Bereitstellungsskripten und Datenbankobjekten.
• Fehlende Dateien oder Updatepfade: Das Zielsystem kann die benötigten Erweiterungsdateien vermissen oder keine passende Aktualisierung von der installierten Erweiterungsversion anbieten.
• Ungeprüfte Wiederherstellung: Ein erfolgreicher Upgrade-Lauf ersetzt weder einen wiederherstellbaren Backup noch einen getesteten Rückfallplan. Ein dedizierter Server verhindert keinen Datenverlust und ist nicht automatisch redundant.

Ergänzen Sie diese technische Prüfung um die betrieblichen Auswirkungen: Wer darf Pakete in der Zielumgebung installieren? Wie werden Änderungen freigegeben? Welche Komponenten greifen während eines geplanten Wechsels auf die Datenbank zu? Insbesondere bei Systemen mit Anforderungen an Datenschutz und DSGVO sollten Sie außerdem dokumentieren, wo Testdaten und Sicherungskopien liegen und wer darauf zugreifen kann.

Bestandsaufnahme: Installiert ist nicht gleich tatsächlich verwendet

Wie ermitteln Sie installierte Erweiterungen vor dem Upgrade?

Führen Sie die Bestandsaufnahme für jede Datenbank einzeln aus. Die Systemkataloge einer Verbindung geben keine vollständige Datenbankübersicht über alle Datenbanken der Instanz. Mit dieser Abfrage erhalten Sie die dort installierten Erweiterungen und ihre derzeit installierte Version:

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Die Spalten extname und extversion stammen aus dem PostgreSQL-Systemkatalog pg_extension; die offizielle Beschreibung des Katalogs erklärt seine Rolle. Ein beispielhafter Ausgabekopf sieht so aus:

 extname | extversion
---------+-----------

Das ist ein Schema, kein behauptetes Ergebnis für Ihre Instanz. Speichern Sie die tatsächliche Ausgabe mit Datenbankname und Zeitpunkt Ihrer Prüfung. Prüfen Sie anschließend, welche Erweiterungen die Zielinstallation überhaupt als installierbar kennt:

SELECT name, default_version, installed_version
FROM pg_available_extensions
ORDER BY name;

Die Dokumentation zu pg_available_extensions beschreibt die verfügbaren Angaben. Beachten Sie dabei die Trennung: pg_extension ist für den Datenbankbestand maßgeblich; pg_available_extensions liefert Informationen über Pakete, die in der verbundenen Serverumgebung verfügbar sind. Eine installierbare Erweiterung kann in einer bestimmten Datenbank noch unbenutzt sein.

Erweitern Sie das SQL-Inventar um eine Suche nach Erweiterungsabhängigkeiten in Bereitstellungs- und Migrationsskripten, Objektdefinitionen sowie Anwendungscode. Suchen Sie insbesondere nach Funktionsaufrufen, Datentypen, Operatoren und Indexmethoden, die die Erweiterung bereitstellt. Ein automatisierter Suchlauf kann Kandidaten liefern, aber er ersetzt keine Prüfung der tatsächlichen Anwendungsabläufe: Dynamisch erzeugter SQL-Code oder selten verwendete Jobs können bei einer Textsuche unauffällig bleiben.

Zielumgebung: Paketbestand und Updatepfad getrennt bewerten

Sind Erweiterungen in der neuen PostgreSQL-Version noch nutzbar?

Beantworten Sie die Frage für jede Erweiterung einzeln. Halten Sie fest, ob die Zielumgebung das Erweiterungspaket bereitstellt, welche Erweiterungsversion dort verfügbar ist, ob ein Updatepfad von der derzeit installierten Version dokumentiert ist und ob zusätzliche Bibliotheken vorausgesetzt werden. Für diese Prüfung zählen die Dokumentation des Erweiterungsanbieters und die tatsächlichen Dateien der Zielumgebung; ein Treffer mit demselben Namen ist kein Nachweis für eine lauffähige Installation.

Wird die Zielumgebung selbst verwaltet, prüfen Sie Paketquelle und Betriebssystem vor dem Datenbanktest. Die PostgreSQL-Dokumentation zu ALTER EXTENSION beschreibt das Aktualisieren einer installierten Erweiterung; die verfügbaren Aktualisierungsschritte hängen jedoch von den bereitgestellten Erweiterungsskripten ab. Ein passender Befehl kann daher nicht für jede Erweiterung vorausgesetzt werden. Die Referenz zu ALTER EXTENSION erläutert die Syntax und das Verhalten des Befehls.

Notieren Sie bei einem unklaren Befund die offene Frage, anstatt sie als kompatibel oder inkompatibel zu deklarieren. Reproduzieren Sie den Fall in einer isolierten Zielumgebung. Wenn für eine Erweiterung kein dokumentierter Updatepfad erkennbar ist, prüfen Sie mit dem Anbieter eine unterstützte Zwischenaktualisierung oder eine Ersatzlösung. Entfernen Sie sie nicht vorschnell: Die Erweiterung kann Datentypen, Funktionen, Operatoren oder Indexstrukturen bereitstellen, auf die gespeicherte Objekte oder Anwendungscode angewiesen sind.

Was zeigt pg_upgrade bei Erweiterungsproblemen?

Verwenden Sie die Dokumentation der tatsächlich vorgesehenen Zielversion. Die offizielle Referenz für pg_upgrade beschreibt die unterstützten Upgradeverfahren und Prüfungen; für einen Wechsel auf PostgreSQL 18 gilt entsprechend die Dokumentation dieser Zielversion. Prüfen Sie in einer Probeausführung die erzeugten Berichte und Protokolle, statt anzunehmen, ein erfolgreicher Vorabcheck bestätige zugleich die korrekte Funktion der Anwendung.

Ordnen Sie einen Fehler zunächst einer Ursache zu:

1. Dateien fehlen: Das Zielsystem kennt die benötigten Erweiterungsdateien nicht oder findet abhängige Bibliotheken nicht.
2. Aktualisierung ungeklärt: Die Erweiterung ist auffindbar, aber ein unterstützter Versionspfad von der installierten zur verfügbaren Version ist nicht belegt.
3. Objektabhängigkeit offen: Funktionen, Typen, Operatoren oder Indizes werden verwendet, aber ihre Behandlung beim Upgrade ist noch nicht nachvollzogen.
4. Anwendungstest fehlt: Die Werkzeuge melden keinen entsprechenden Blocker, aber die kritischen Abläufe wurden noch nicht ausgeführt.

Ein Prüfbericht ist ein Werkzeug für bekannte technische Voraussetzungen, keine Funktionsabnahme Ihrer Anwendung. Wenn Sie eine Erweiterung ändern oder entfernen wollen, dokumentieren Sie zuerst die abhängigen Objekte und testen Sie die Änderung in einer separaten Umgebung. Löschen Sie weder Erweiterungsobjekte noch Datenbankbestand, um einen Prüflauf „grün“ zu bekommen.

Funktionstest und Cutover: Entscheidung nach Befund

Muss eine Erweiterung nach dem PostgreSQL-Upgrade separat aktualisiert werden?

Das hängt von Erweiterung, derzeitiger Version, Zielumgebung und dem vorgesehenen Upgradepfad ab. Prüfen Sie die verfügbaren Erweiterungsinformationen im Zielsystem und die Anbieterhinweise; führen Sie ein notwendiges Erweiterungsupdate gezielt nach dem dokumentierten Verfahren aus. Das Datenbankupgrade allein belegt nicht, dass alle Erweiterungen bereits auf der gewünschten Version sind. Umgekehrt sollten Sie keine Aktualisierung einplanen, nur weil die Hauptversion von PostgreSQL wechselt.

Testen Sie in einer isolierten Umgebung die Funktionen, die Ihre Anwendung tatsächlich aufruft: wichtige Abfragen, Funktionsaufrufe, betroffene Datentypen und Indexverhalten. Nehmen Sie außerdem Verbindungen, ORM-Konfiguration, Migrationsskripte und Backup- beziehungsweise Wiederherstellungswerkzeuge in den Test auf. Halten Sie pro Test die Zielversion, Paket- und Erweiterungsversionen, Schritte, Beobachtungen und den vorgesehenen Rückfall fest. Ohne eigene Messung sollten Sie keine Leistungsverbesserung oder Erfolgsquote behaupten.

Ein sinnvoller Ablauf ist:

1. Bestand sichern: Erfassen Sie pro Datenbank installierte Erweiterungen und Versionen; ergänzen Sie bekannte Abhängigkeiten aus Anwendung und Deployments.
2. Zielumgebung aufbauen: Stellen Sie Betriebssystem, PostgreSQL-Zielversion und Erweiterungspakete getrennt bereit. Kontrollieren Sie, dass die Pakete aus nachvollziehbaren Quellen stammen.
3. Kompatibilität prüfen: Dokumentieren Sie Verfügbarkeit, Updatepfad, benötigte Bibliotheken und offene Anbieterfragen für jede Erweiterung.
4. Upgrade-Probe durchführen: Folgen Sie dem offiziellen Verfahren für die Zielversion und bewerten Sie Prüfbericht sowie Protokolle.
5. Funktionen testen: Spielen Sie typische und kritische Anwendungsabläufe durch; prüfen Sie Fehlerbehandlung, Datenobjekte und Wiederherstellung.
6. Sicherung wiederherstellen: Verifizieren Sie in einer getrennten Umgebung, dass Ihr Backup tatsächlich eingelesen werden kann. Die offizielle Dokumentation zu Sicherung und Wiederherstellung beschreibt die PostgreSQL-Verfahren.
7. Cutover freigeben: Wechseln Sie erst, wenn Erweiterungsbestand, Anwendungstests, Sicherung und Rückfallverfahren dokumentiert und freigegeben sind.

Für eine Entscheidung vor dem Produktionswechsel verwenden Sie diese Bedingungen:

• Wenn jede installierte Erweiterung im Ziel verfügbar ist, der Updatepfad geklärt wurde, die Anwendungstests bestanden sind und ein Backup wiederhergestellt werden konnte, dann können Sie den Cutover nach Ihrem Wartungs- und Rückfallplan freigeben.
• Wenn Dateien oder ein Updatepfad fehlen, dann stoppen Sie den Wechsel und klären Paketquelle, Anbieterfreigabe oder Ersatzlösung zuerst in der isolierten Umgebung.
• Wenn der technische Vorabcheck besteht, aber Anwendungsfunktionen oder Wiederherstellung nicht getestet wurden, dann ist die Freigabe noch nicht vollständig.
• Wenn die Prüfungen bis zum Ende des Supportzeitraums nicht abgeschlossen sind, dann planen Sie keine ungeprobte Produktionsumstellung allein nach Kalenderdruck; priorisieren Sie eine kontrollierte, belegbare Vorgehensweise mit Verantwortlichen für Risiko und Betrieb.

Drei Übersichten für die Freigabe

Die Tabellen bündeln Prüfpunkte, ersetzen aber weder Protokolle noch Tests. Erfassen Sie reale Ergebnisse aus Ihrer Instanz; die Beispiele enthalten bewusst keine erfundenen Kompatibilitätsurteile.

Zielserver planen, ohne Betrieb und Produkt zu verwechseln

Für einen selbst verwalteten Datenbankserver prüfen Sie die Zielressourcen anhand Ihrer realen Datenbankgröße, Erweiterungen, Parallelität und Wiederherstellungsanforderungen. OSFP Cloud nennt für seine dedizierten AMD-Server einen AMD EPYC 7543P mit 32 Kernen und 64 Threads sowie 128 GB oder 256 GB DDR4-3200-ECC-Arbeitsspeicher. Die Ausstattung umfasst zwei direkt angebundene NVMe-Laufwerke mit jeweils 1 TB; weitere NVMe-Laufwerke können laut bereitgestellten Produktdaten ergänzt werden. Die Systeme haben kein Hardware-RAID: Redundanz müssen Sie selbst über Software-RAID oder Replikation planen, und ein Backup gehört auf ein externes System.

Die Ausstattung ist keine Aussage darüber, ob eine bestimmte Erweiterung mit Ihrer Zielversion kompatibel ist. Prüfen Sie außerdem, welches Betriebssystem Sie für die Zielumgebung einsetzen und ob benötigte Datenbank- und Erweiterungspakete dafür verfügbar sind. Für die Beurteilung der Speicherkapazität und Laufwerksaufteilung können Sie die Hinweise zu Arbeitsspeicher und Datenträgern heranziehen. Den Administrationszugang über SSH erläutert die Zugriffsinformation.

Wenn Ihre Erweiterungsprüfungen noch offen sind, behebt ein Serverwechsel diese Unsicherheit nicht: Ein Umzug auf Bare Metal ändert weder den Updatepfad einer Erweiterung noch ersetzt er Tests und Backups. Prüfen Sie zuerst Ihre Zielversion, Installation und Wiederherstellung. Wenn Sie danach eine dauerhaft selbst verwaltete Umgebung benötigen, vergleichen Sie Ihre konkreten Ressourcenanforderungen mit den Angaben zu den dedizierten Servern von OSFP Cloud. Eine verwaltete Datenbank kann für Teams mit wenig Betriebsressourcen weiterhin die passendere Wahl sein; bei selbst betriebenen Systemen tragen Sie dagegen Paketpflege, Erweiterungstests, Redundanz und Wiederherstellung selbst.