PostgreSQL 19 kommt später und mit weniger Funktionen
Die PostgreSQL Global Development Group verschiebt die Veröffentlichung von PostgreSQL 19. Statt Ende September oder Anfang Oktober soll die neue Hauptversion voraussichtlich am 19. November erscheinen.
Gleichzeitig wurden acht bis zehn bedeutende Funktionen aus dem geplanten Release entfernt. Sie sollen nach weiterer Überarbeitung mit PostgreSQL 20 ausgeliefert werden. Auslöser waren LLM-gestützte Code-Reviews, die deutlich mehr Probleme sichtbar machten, als das Entwicklerteam vor dem geplanten Termin bearbeiten konnte.
| Planungspunkt | Bisheriger Stand | Neuer Stand |
|---|---|---|
| Veröffentlichung | Ende September oder Anfang Oktober | Voraussichtlich 19. November |
| Verschobene Funktionen | Für PostgreSQL 19 vorgesehen | 8 bis 10 Funktionen für PostgreSQL 20 |
| Beispielhafte Fehlerlast | Einzelne Randfälle | Listen mit rund 40 Fehlerberichten |
| Typischer Korrekturumfang | Nicht beziffert | Im Beispiel durchschnittlich 3 Codezeilen je Fehler |
KI findet kleine Fehler schneller, beseitigt aber nicht den Aufwand
Peter Eisentraut, PostgreSQL-Committer und Vice President bei EDB, nennt zwei Arten von Problemen. Einige zurückgezogene Funktionen hätten erhebliche architektonische Mängel enthalten, die sich während der Betaphase nicht kurzfristig beheben ließen. Hinzu kam eine große Zahl vergleichsweise kleiner Randfall-Fehler.
Sinngemäß erklärte Eisentraut: Mit LLM-gestütztem Code-Review werden solche Probleme viel schneller entdeckt. Selbst bei rund 40 Fehlerberichten mit durchschnittlich nur drei zu ändernden Codezeilen entsteht für jeden einzelnen Fall ein fester Prüfungs-, Korrektur- und Verwaltungsaufwand.
Damit zeigt sich eine praktische Grenze automatisierter Prüfungen. Ein LLM kann die Suche nach verdächtigen Stellen stark beschleunigen, doch Bewertung, Korrektur, Tests und Freigabe bleiben arbeitsintensiv. Mehr gefundene Fehler bedeuten zunächst auch mehr Arbeit für das menschliche Team.
Welche Modelle oder Werkzeuge bei PostgreSQL eingesetzt wurden, ist nicht bekannt. Die Entwicklung passt jedoch zu einer breiteren Verschiebung beim Einsatz von KI im Software Engineering. Statt ausschließlich neuen Code zu erzeugen, kann KI vorhandene Implementierungen systematisch auf Inkonsistenzen und seltene Fehlerzustände untersuchen. Wie groß die Distanz zwischen Nutzung und Vertrauen weiterhin ist, zeigt auch die Analyse zur Akzeptanz von KI-Coding unter Entwicklern.
Keine Folge von Vibe Coding
Eisentraut weist ausdrücklich zurück, dass die Probleme durch unkontrollierte KI-Codegenerierung entstanden seien. Die betroffenen Funktionen wurden überwiegend entwickelt, bevor entsprechende Verfahren breit verfügbar waren.
Verändert hat sich vielmehr die Qualität der Prüfwerkzeuge. In den Monaten vor dem geplanten Release wurden LLM-gestützte Reviews leistungsfähiger und ihr Einsatz besser verstanden. Dadurch stieg der Qualitätsmaßstab, nachdem Teile des Codes bereits geschrieben und in das Projekt aufgenommen worden waren.
Sinngemäß formuliert: Die tatsächliche Qualitätslatte wurde erst angehoben, nachdem die Funktionen bereits entwickelt und übernommen worden waren.
Der Fall unterscheidet sich damit von Projekten, bei denen KI möglichst schnell große Mengen neuen Codes erzeugt. Er zeigt KI als zusätzliche Kontrollinstanz. Ein anderes Beispiel für den Einsatz von KI in umfangreichen Entwicklungsarbeiten ist der KI-gestützte Port von TypeScript nach Rust, bei dem ebenfalls Aufwand, Kosten und menschliche Kontrolle entscheidend bleiben.
SQL/PGQ wird auf PostgreSQL 20 verschoben
Zu den entfernten Funktionen gehört die Unterstützung für SQL Property Graph Queries, kurz SQL/PGQ. Der 2023 in den SQL-Standard aufgenommene Ansatz ermöglicht Abfragen auf Eigenschaftsgraphen. Dabei werden Daten als Knoten, Verbindungen und zugehörige Eigenschaften betrachtet.
Die PostgreSQL-Implementierung enthielt noch ungelöste Probleme. Entwickler Tom Lane warnte sinngemäß, dass bei einer Auslieferung in Version 19 nachträglich Fehler auftauchen könnten, die sich bis PostgreSQL 20 nicht mehr sauber beheben ließen.
Welche weiteren Funktionen aus PostgreSQL 19 entfernt wurden, ist nicht vollständig aufgeschlüsselt. Bestätigt ist lediglich die Größenordnung von acht bis zehn signifikanten Änderungen.
REPACK CONCURRENTLY bleibt Teil des Releases
PostgreSQL 19 wird trotz der Kürzungen eine wichtige Neuerung enthalten. REPACK CONCURRENTLY soll Speicherplatz zurückgewinnen können, ohne die bislang bei VACUUM FULL erforderliche Tabellensperre auszulösen.
Für produktive Datenbanken ist das relevant, weil lang laufende Sperren Anwendungen beeinträchtigen können. Die Funktion zielt damit auf einen alltäglichen Betriebsfall und nicht nur auf neue Abfragemöglichkeiten.
Unternehmen müssen Upgrade-Pläne anpassen
PostgreSQL gehört im DACH-Raum zu den Standarddatenbanken für selbst gehostete Unternehmensanwendungen, datenschutzorientierte On-Premise-Systeme und Cloud-native Eigenentwicklungen. IT-Abteilungen, die Tests oder Migrationen für das Jahresende eingeplant haben, müssen ihre Zeitpläne an den neuen Veröffentlichungstermin anpassen.
Wer auf SQL/PGQ oder eine der anderen verschobenen Funktionen angewiesen ist, muss voraussichtlich bis PostgreSQL 20 warten oder eine alternative Umsetzung prüfen. Bestehende Installationen sind von der Verschiebung zunächst nicht betroffen.
Aus Sicht von Open Source und Self-Hosting ist die Verzögerung dennoch ein positives Qualitätssignal. Das Projekt priorisiert eine belastbare Datenbankbasis vor einem starren Termin. Proprietäre Datenbankabonnements vermeiden solche Zielkonflikte nicht automatisch, entziehen Unternehmen aber häufig die Transparenz darüber, wie technische Entscheidungen und Qualitätsprüfungen zustande kommen.
Der kurzfristige Preis sind verschobene Funktionen und zusätzlicher Planungsaufwand. Langfristig kann die gründlichere Prüfung das Risiko späterer Ausfälle und schwer korrigierbarer Architekturfehler senken. Eisentraut erwartet entsprechend, dass PostgreSQL 19 nach der zusätzlichen Kontrolle besonders robust ausfallen wird.