Das PostgreSQL-Projekt gibt die Version 19 seiner Datenbank voraussichtlich erst am 19. November frei, rund acht Wochen später als die Vorgänger. Den Grund sieht Robert Haas, einer der Kernentwickler des Projekts, in Sprachmodellen, die Fehler im rund 40 Jahre alten Code schneller aufspüren, als die Entwickler sie beheben können.[1]
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 4 Abschnitte
Zehn Jahre lang erschienen neue Hauptversionen zwischen Mitte September und Mitte Oktober, PostgreSQL 18 am 25. September 2025.[3] Am 12. November kommt zunächst ein zweiter Release Candidate, also eine letzte Testversion, zusammen mit einem Wartungsupdate, das laut Ankündigung eine große Zahl von Korrekturen enthält.[2]
Das Wichtigste in Kürze
- PostgreSQL 19 soll am 19. November erscheinen, rund acht Wochen später als Version 18.
- Laut Robert Haas finden Sprachmodelle so viele Fehler, dass die nachträglichen Korrekturen um über 60 Prozent zunahmen.
- Drei größere Funktionen flogen im Spätsommer wieder aus der Version.
- Das große Wartungsupdate am 12. November ist das letzte für PostgreSQL 14.
Woran lässt sich der Anstieg ablesen?
Haas vergleicht die Zeit vom Feature-Freeze am 8. April, ab dem keine neuen Funktionen mehr hinzukommen, bis zum 25. September. 2025 wurden in dieser Zeit 724 Korrekturen in PostgreSQL 18 übernommen, 2026 waren es 1.169 in Version 19. Auf die jeweils ältere Version wurden 433 statt 248 Korrekturen übertragen, ein Plus von rund 75 Prozent. Die Zahl neuer Änderungen im Hauptzweig sank dagegen leicht.[1] Haas schließt daraus, dass die Entwickler nicht mehr Fehler machen als früher, sondern dass alte Fehler schneller auffallen.
Auf der Sicherheitsseite des Projekts stehen 44 Lücken mit einer CVE-Nummer aus dem Jahr 2026, gegenüber 7 aus dem Jahr 2025. Bei vielen lautet die Folge, dass Angreifer beliebigen Code ausführen können.[4] Ob die Funde von Sprachmodellen stammen, geht aus der Übersicht nicht hervor. Zwischen dem 27. August und dem 15. September strich das Projekt zudem drei größere Funktionen, darunter Graphabfragen nach SQL/PGQ.[1]
Warum wird das Beheben zum Engpass?
Die Korrekturvorschläge der Sprachmodelle sind laut Haas nicht immer richtig und entsprechen nicht immer den Standards des Projekts, deshalb prüfen und übernehmen weiterhin Menschen jede Änderung. Die Zeit für die Prüfung der neuen Version floss in Sicherheitskorrekturen für ältere Versionen.[1]
Auch anderswo wächst der Druck. Das Sicherheitsteam von WordPress hat in diesem Jahr über 3.000 Meldungen erhalten, Google hat im Juni mehr Chrome-Lücken geschlossen als in den zwei Jahren davor zusammen. Beim Projekt curl lag das Problem woanders: Daniel Stenberg hat das Bug-Bounty-Programm, das Belohnungen für gemeldete Lücken zahlte, zum 31. Januar 2026 beendet, weil sich minderwertige Meldungen häuften, die oft von KI erzeugt waren.[5] Haas beschreibt bei PostgreSQL dagegen vor allem berechtigte Funde.
Die KI hat die Fehlersuche billig gemacht, das Beheben nicht. Bei PostgreSQL kostet dieser Unterschied acht Wochen.
Markus Seyfferth, Chefredakteur Dr. Web
Die Zahlen
Der Zeitplan
Was sollten Betreiber und Hersteller tun?
Hersteller, die PostgreSQL in Produkte einbauen, trifft zusätzlich die Cyberresilienzverordnung der EU. Seit dem 11. September 2026 müssen sie aktiv ausgenutzte Schwachstellen binnen 24 Stunden als Frühwarnung an die ENISA und das zuständige CSIRT melden. Stellen sie eine Lücke in einer quelloffenen Komponente fest, melden sie diese auch dem Projekt, das die Komponente pflegt.[6] In Deutschland soll das BSI für die Aufsicht 141 zusätzliche Stellen bekommen.
- Update einplanen: Das Wartungsupdate vom 12. November für alle unterstützten Versionen zeitnah einspielen.[2]
- PostgreSQL 14 ablösen: Für diese Version erscheint am 12. November die letzte Aktualisierung, danach gilt sie als nicht mehr unterstützt.[3]
- Umstieg testen: Den Wechsel auf Version 19 mit dem zweiten Release Candidate proben und erst die stabile Version produktiv einsetzen.[2]
Haas hält die Verspätung für vertretbar, die langfristige Lage für schwieriger: Wie das Projekt die Fehler aus 40 Jahren abarbeiten und trotzdem Neues entwickeln soll, weiß er nach eigenen Worten noch nicht.[1] Was Angreifer mit Sprachmodellen finden können, sollten Entwicklerteams vorher selbst mit einer KI-Prüfung suchen.
Quellen
6 Quellen anzeigenQuellen ausblenden
- Robert Haas, Neon-BlogPostgres 19 is late, and it’s AI’s fault
- PostgreSQL Global Development GroupPostgreSQL 19 RC 1 Released!
- PostgreSQLVersioning Policy, abgerufen am 2. November 2026
- PostgreSQLSecurity Information, abgerufen am 2. November 2026
- Daniel StenbergThe end of the curl bug-bounty
- EUR-LexVerordnung (EU) 2024/2847 (Cyberresilienzverordnung), Artikel 13, 14 und 71
Mehr Newshunger?
- Kritische Linux-Sicherheitslücke CVE-2026-98432: Server mit Go-Programmen sind standardmäßig angreifbar
- Altman glaubt nicht mehr, dass sich alle Sicherheitslücken schließen lassen
- Linus Torvalds legt KI-gestützte Kernel-Patches vor: im synthetischen Test 23-mal schneller
- Anthropic: Sprachmodelle machen formale Softwareverifikation in großem Maßstab möglich
- Beim Code-Review ging es nie um den Code, sagt Designer Matt Ström-Awn
- Für 22 Euro gefunden: Wie eine KI die kritische WordPress-Lücke aufgespürt hat
- Nginx: Drei kritische Sicherheitslücken im Webserver fast jeder dritten Website
