Bugs vinden gaat sneller dan herstellen: waarom PostgreSQL 19 later komt

Of: wat er gebeurt als fouten vinden goedkoop wordt en fouten herstellen niet

Er is een oude grap onder programmeurs: elk programma bevat nog minstens één bug. Lang was dat vooral een troost, want wie die bug wilde vinden, had er werk aan. In 2026 is het vinden goedkoop geworden. Het herstellen niet. PostgreSQL, een van de belangrijkste opensource databases ter wereld, merkt nu wat dat betekent: de nieuwe versie is te laat, en een van de ontwikkelaars vraagt zich hardop af hoe het project ooit nog bijbeent.

PostgreSQL 19 later door AI: wat er gebeurde

De database onder je boekhouding

PostgreSQL is een database: het programma dat de gegevens van een toepassing bijhoudt en terugvindt. Je ziet het nooit, maar het zit onder heel wat software die je wel ziet. Odoo, het Belgische pakket voor bedrijfsbeheer, draait erop, net als talloze webshops, SaaS-diensten en interne tools. Het project is zo oud dat de geschiedenis van de code meer dan dertig jaar teruggaat.¹

Elk jaar verschijnt er een nieuwe hoofdversie. De voorbije tien jaar viel die telkens tussen half september en half oktober. PostgreSQL 19 komt op zijn vroegst op 19 november, na een tweede testversie op 12 november. De officiële reden voor die extra testversie: de onderhoudsupdate van 12 november voor de bestaande versies bevat „een groot aantal correcties”, en het team wil die eerst ook in versie 19 hebben.

Onderweg verliest de nieuwe versie ook functies. Tussen 27 augustus en 15 september werden er drie grote teruggedraaid, waaronder zoekopdrachten op grafen met SQL/PGQ.² Peter Eisentraut, een van de ontwikkelaars die code aan PostgreSQL mogen toevoegen en vicepresident bij het databasebedrijf EDB, telt acht tot tien belangrijke functies die naar PostgreSQL 20 verhuizen, afhankelijk van hoe je telt.

De cijfers van Robert Haas

Robert Haas, eveneens zo’n ontwikkelaar en ingenieur bij Databricks, zocht eind oktober op zijn blog uit waar de tijd naartoe ging. Hij vergeleek telkens de periode van 8 april, de dag waarop er geen nieuwe functies meer bij mochten, tot 25 september. In 2025 ging het om versie 18, in 2026 om versie 19.

Het werk dat alleen voor de volgende versies bedoeld was, daalde licht. De ontwikkelaars werkten dus niet minder; ze waren bezig met herstellen in plaats van bouwen. En een correctie die ook naar oudere versies moet, is meer werk dan ze lijkt.³

Volgens Haas maken de ontwikkelaars niet meer fouten dan vroeger. De fouten waren er altijd al; ze zijn alleen veel makkelijker te vinden, door taalmodellen die de code doorlichten. Herstellen gaat met AI ook makkelijker, maar lang niet in dezelfde mate. Een correctie die een taalmodel voorstelt, klopt niet altijd en volgt niet altijd de regels van het project, dus een mens moet ze nakijken en toevoegen. De uren die daarin kropen, gingen niet naar het nakijken van de nieuwe functies van versie 19.

Een kanttekening: de cijfers tonen niet hoeveel fouten precies door AI gevonden werden. Dat AI de grote oorzaak is, is de inschatting van Haas. Eisentraut komt wel tot dezelfde conclusie.

Veertig meldingen van drie regels

Eisentraut legde het begin oktober op zijn eigen blog uit. Nazicht met een taalmodel vindt een lange staart van vrij onschuldige problemen in randgevallen. Vroeger kwamen die één voor één boven in de vijf jaar na de lancering, via gewone bugfixes. Nu sta je vóór de lancering voor een lijst van veertig meldingen. Ook als elke correctie gemiddeld maar drie regels code vraagt, heeft elke melding een vaste kost: begrijpen, nakijken, testen, bespreken. Veertig keer.

Eén verklaring wijst hij uitdrukkelijk af: de functies die sneuvelden, waren niet door AI geschreven. De meeste dateren van voor de tijd dat zulke technieken bruikbaar waren. Het is het nazicht dat beter werd, en daarmee ging de lat omhoog voor code die al was toegevoegd.

Vergelijk het met een garage die een nieuw diagnosetoestel krijgt. Het toestel vindt bij elke auto die binnenkomt twintig kleine problemen die vroeger niemand zag. Allemaal echt, en de auto’s worden er veiliger van. Alleen heeft de garage nog altijd dezelfde mecaniciens, en die staan nu oude auto’s bij te werken in plaats van de nieuwe wagens af te leveren. Het toestel heeft niemand slechter in zijn werk gemaakt. Het toont alleen hoeveel werk er altijd al lag.

„Hoe gaan we dit ooit inhalen?”

Over de vertraging zelf maakt Haas zich geen zorgen: ze is kort, en ze toont dat het project kwaliteit voorrang geeft. Hij noemt de code van PostgreSQL zelfs een van de netste waaraan hij ooit werkte. Het langere verhaal vindt hij minder duidelijk, en in sommige opzichten zorgwekkender. Decennia aan code, en een technologie die er nu systematisch de oude fouten uithaalt: hoe gaan we dat ooit inhalen, vraagt hij, en hoe blijven we intussen vernieuwen? Het antwoord heeft hij nog niet, schrijft hij. Hij en anderen zoeken het.

Het is het soort probleem dat succes veroorzaakt. Google zag dit jaar het aantal gemelde softwarelekken verdubbelen, mee door AI. Het beveiligingsbedrijf depthfirst vond met een eigen AI-model een lek waarmee een proces uit een Linux-container ontsnapt. Elke melding is goed nieuws voor wie de software gebruikt. Ze komt alleen terecht bij een kleine groep mensen met een beperkt aantal uren. Het vinden schaalt met rekenkracht. Het herstellen schaalt met mensen.

Kmo-Kristof: Dus AI vindt meer fouten in die database. Dan wordt ze toch beter?

Security-Sofie: Ja. Alleen later.

Kmo-Kristof: Laat AI de fouten dan ook oplossen.

Security-Sofie: Dat doet het al. Daarna moet een mens nakijken of de oplossing klopt.

Kmo-Kristof: Ik ken dat. Mijn boekhoudtool met AI vond vorige maand dertig fouten in mijn facturen.

Security-Sofie: En?

Kmo-Kristof: Drie verbeterd. De rest staat op een lijstje.

Security-Sofie: Proficiat. Je bent een opensourceproject.

Wat betekent dit voor jou?

• Je merkt het vooral onrechtstreeks. Gebruik je Odoo, een webshop of een SaaS-dienst, dan beslist je leverancier of partner wanneer er een nieuwe PostgreSQL-versie onder komt. Vraag gerust welke versie er draait en hoe snel updates volgen.
• Installeer de onderhoudsupdate van 12 november als je zelf een PostgreSQL-server beheert. Volgens het project bevat ze een groot aantal correcties, en precies in zulke kleine updates belanden de fouten die AI nu vindt.
• Spring niet op dag één naar versie 19. Een overstap naar een nieuwe hoofdversie vraagt een aparte migratie, met pg_upgrade of met een export en import. Wacht liever op de eerste onderhoudsupdate, zeker nu de testfase onder druk stond.
• Ken je afhankelijkheden. Wie op opensourcesoftware bouwt, hangt af van de uren van een kleine groep mensen. Een nagekeken, gedetailleerde foutmelding helpt hen. Een ruwe lijst uit een taalmodel kost hen tijd.

De oude grap klopte dus: er zat altijd nog een bug in. Alleen wist niemand dat het er zoveel waren. Nu iedereen het weet, is de vraag niet meer wie ze vindt, maar wie er tijd voor heeft.