PostgreSQL 19 verspätet sich: KI-Fehlerberichte bremsen Release
PostgreSQL 19 kommt später als üblich. Entwickler Robert Haas führt das auf viele mit KI gefundene Fehler und deren Rückportierung zurück, mehrere große Funktionen wurden spät entfernt. Was das für die Upgrade-Planung bedeutet und warum PostgreSQL 14 Vorrang hat.
PostgreSQL 19 erscheint nicht wie gewohnt bis Mitte Oktober. Der langjährige PostgreSQL-Entwickler Robert Haas schreibt in einem Blogbeitrag vom 30. Oktober 2026, die neue Hauptversion komme voraussichtlich erst im November, eine weitere Verschiebung sei nicht ausgeschlossen. Als Hauptgrund nennt er eine Flut von Fehlerberichten, die mit Hilfe großer Sprachmodelle gefunden wurden.
Für den laufenden Betrieb ändert sich nichts: Die unterstützten Versionen erhalten weiter Minor-Updates. Relevant ist die Verzögerung für Teams, die ein Upgrade auf Version 19 eingeplant haben. Dringender ist für viele Admins ohnehin ein anderes Datum: PostgreSQL 14 erreicht am 12. November 2026 sein Supportende.
Was ist passiert?
Laut Haas lagen PostgreSQL-Hauptversionen im vergangenen Jahrzehnt verlässlich zwischen Mitte September und Mitte Oktober. In diesem Jahr wurden zudem mehrere große Funktionen spät in der Betaphase wieder entfernt: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ) sowie ALTER TABLE … MERGE PARTITION/SPLIT PARTITION, alle zwischen dem 27. August und dem 15. September.
Haas belegt die Mehrarbeit mit Zahlen. Zwischen Feature Freeze am 8. April und dem 25. September gingen 2025 insgesamt 1.037 Commits in den Master-Zweig und 724 in REL_18_STABLE. Im selben Zeitraum 2026 waren es 1.443 Commits im Master und 1.169 in REL_19_STABLE. Rückportierungen in den Zweig der Vorversion stiegen von 248 auf 433. Viele Fehler würden inzwischen mit Sprachmodellen gefunden und gemeldet. Korrekturen müssten aber weiterhin von Menschen geprüft und eingespielt werden, und diese Zeit fehle bei der Prüfung des neuen Releases.
Haas hält die Verzögerung selbst für unbedenklich, weil sie aus dem Qualitätsanspruch des Projekts folge. Langfristig sieht er die Frage, wie das Projekt mit der Menge an gefundenen Altfehlern Schritt halten und zugleich weiterentwickeln kann, als offen. LWN und Phoronix greifen den Beitrag auf; eine neue offizielle Terminangabe nennt keine der Quellen.
Für wen ist das relevant?
Relevant ist die Meldung für Datenbankadmins und Entwicklerteams, die PostgreSQL 19 testen oder einen Umstieg terminiert haben, sowie für Betreiber, die auf die zurückgezogenen Funktionen gewartet haben. Die offizielle Roadmap nennt für Version 19 weiterhin Oktober 2026; auf der Projektseite ist ein Release Candidate 1 vom 15. Oktober 2026 angekündigt.
Wie wichtig ist das?
Für die Sicherheit bestehender Installationen ist die Verschiebung unkritisch. Die vielen Rückportierungen bedeuten aber, dass Minor-Updates derzeit besonders viele Korrekturen enthalten. Das nächste planmäßige Minor-Release steht laut Roadmap am 12. November 2026 an.
Was sollten Admins jetzt tun?
- Inventar prüfen: Welche Hauptversion läuft auf welchem Server?
SELECT version();liefert die genaue Angabe. - Instanzen mit PostgreSQL 14 priorisieren. Laut Versionierungsrichtlinie endet der Support am 12. November 2026, danach gibt es keine Fehler- und Sicherheitskorrekturen mehr.
- Upgrade-Ziel festlegen: Wer nicht auf Version 19 warten will, kann auf PostgreSQL 18 (aktuell 18.6, Support bis November 2030) wechseln. Hauptversionen erfordern
pg_upgradeoder Dump und Restore. - Minor-Updates zeitnah einspielen, insbesondere das Release vom 12. November. Versionshinweise vorher lesen.
- Wer Funktionen wie SQL/PGQ oder
FOR PORTION OFeingeplant hat, sollte die Planung anpassen: Diese Funktionen sind nicht Teil von PostgreSQL 19.
Einordnung für Unternehmen
Für Unternehmen ist eine Hauptversion wenige Wochen später kaum ein Problem; die meisten warten ohnehin einige Minor-Releases ab. Wichtiger ist die Beobachtung dahinter: KI-gestützte Fehlersuche erhöht die Zahl der Korrekturen in allen gepflegten Zweigen. Wer Datenbanken betreibt, sollte Minor-Updates als Routine mit festem Wartungsfenster behandeln und das Supportende jeder Hauptversion im Blick behalten.
Passende Anleitungen auf S-EDV
- PostgreSQL mit pg_dump und pg_restore sichern und migrieren
- PostgreSQL nativ unter Ubuntu aus dem PGDG-Repository installieren
- MySQL- und PostgreSQL-Backups automatisieren
