Die unsichtbare Grundlage
Eine Anwendung bekommt neue Masken, zusätzliche Funktionen und ein überarbeitetes Design. Die Datenbank darunter bleibt dagegen jahrelang außerhalb der Aufmerksamkeit. Erst eine langsame Suche oder ein anstehender Versionswechsel macht sichtbar, wie viel von ihr abhängt.
Ich würde die Datenbank nicht erst dann auf die Tagesordnung setzen, wenn es weh tut. Sie ist Teil des Produkts, auch wenn ihre Versionsnummer im täglichen Betrieb niemand sieht.
Zwei Termine, die man nicht verwechseln sollte
PostgreSQL 19 RC 1 wurde am 15. Oktober 2026 veröffentlicht. Die allgemeine Freigabe ist für den 19. November 2026 geplant; der Zeitplan kann sich ändern. Ein Release Candidate ist noch keine endgültig freigegebene Produktivversion. [1]
Für PostgreSQL 14 nennt das Projekt dagegen den 12. November 2026 als Ende seines regulären Supports. [2] Das liegt vor dem geplanten Termin für Version 19. Ich würde deshalb auf eine geeignete, bereits freigegebene und unterstützte Version planen, statt ausschließlich auf die höchste Nummer zu warten. Gesonderte Herstellerverträge sind davon getrennt zu betrachten.
Welche Grundlage betreiben wir überhaupt?
Mein erster Schritt wäre eine kurze, belastbare Bestandsaufnahme: Welche Datenbankversion läuft tatsächlich? Welche Anwendungen und Erweiterungen hängen daran? Wer pflegt sie? Und wer entscheidet über Wartungsfenster und Freigabe?
Eine solche Übersicht muss nicht groß sein. Sie sollte aber einen Verantwortlichen und einen überprüften Stand enthalten. „Das macht unser Hoster“ beantwortet noch nicht, ob die Zuständigkeit vertraglich und praktisch wirklich geklärt ist.
Neue Funktionen sind kein pauschales Geschwindigkeitsversprechen
Die Vorab-Dokumentation von PostgreSQL 19 beschreibt unter anderem Änderungen an Wartung, Abfrageplanung und Replikation. Diese Angaben beziehen sich auf eine noch nicht endgültig veröffentlichte Version. [3]
Für eine konkrete Anwendung würde ich daraus keine Prozentzahl zur Beschleunigung ableiten. Ich würde zuerst deren tatsächliche Abfragen, Datenmengen und Engpässe betrachten. Eine neue Oberfläche kann eine unpassende Datenstruktur nicht einfach unsichtbar machen. Umgekehrt ist eine langsame Suche nicht automatisch ein Beweis, dass eine neue Datenbankversion benötigt wird.
Versionswechsel als eigenes Vorhaben behandeln
PostgreSQL unterscheidet Hauptversionswechsel von kleineren Aktualisierungen. Ein Wechsel der Hauptversion benötigt ein dafür vorgesehenes Migrationsverfahren und einen Blick auf Kompatibilitätsänderungen. [2]
Ich würde vor der Freigabe prüfen, ob Anwendung, Treiber und Erweiterungen mit dem Zielstand zusammenarbeiten. Ein kontrollierter Probelauf braucht repräsentative, zulässig verwendete Daten. Anschließend gehören nicht nur der Start, sondern auch Suche, Schreiben, Berichte und die wichtigen Hintergrundaufgaben auf den Prüfplan.
Ein Backup ist erst der Anfang des Rückwegs
Die PostgreSQL-Dokumentation beschreibt unterschiedliche Sicherungsverfahren mit unterschiedlichen Voraussetzungen. [4] Das ist ein guter Grund, die Wiederherstellung nicht als beliebiges Kopieren eines Verzeichnisses zu behandeln.
Ich würde wissen wollen, wann zuletzt eine Wiederherstellung in einer getrennten Umgebung gelang und was dabei tatsächlich geprüft wurde. Auch ein Rückweg nach der Umstellung braucht eine klare Entscheidung: Neue Schreibvorgänge auf dem Zielsystem verschwinden nicht dadurch, dass die alte Installation noch vorhanden ist. Wie sie erhalten oder abgeglichen werden, muss vorab geklärt sein.
Mein Fazit
Gute Softwarepflege endet nicht an der sichtbaren Oberfläche. Datenhaltung, Supportzeitraum, Wiederherstellung und Verantwortlichkeiten gehören zusammen.
Die genannten Termine geben den Projektstand vom 23. Oktober 2026 wieder. Sie sind keine Upgrade-Anweisung für eine bestimmte Installation. Welche Zielversion geeignet ist, muss anhand der unterstützten Anwendung und ihrer Abhängigkeiten entschieden werden.
Quellen und Einordnung
Recherchestand: 23. Oktober 2026. Herstellerveröffentlichungen sind keine eigenen Produktprüfungen. Beispiele und Empfehlungen sind im Text als solche eingeordnet.
[1] PostgreSQL: Version 19 RC 1 und geplanter Releasezeitplan, 15.10.2026
Quelle lesen ↗
[2] PostgreSQL: Versions- und Supportpolitik
Quelle lesen ↗
[3] PostgreSQL 19: vorläufige Release Notes, Entwicklungsstand
Quelle lesen ↗
[4] PostgreSQL 18: Sicherung und Wiederherstellung
Quelle lesen ↗