Les relecteurs IA repoussent PostgreSQL 19 à novembre et renvoient jusqu’à dix fonctionnalités à la version 20

16 octobre 2026. Le groupe de développement de PostgreSQL annonce le report de PostgreSQL 19, attendu pour fin septembre ou début octobre. 19 novembre 2026. La sortie est désormais prévue pour cette date, et huit à dix fonctionnalités majeures sont retirées du cycle. 9 octobre 2026. Le committer Peter Eisentraut publie le billet « The reverts will continue until morale improves » qui explique pourquoi. Le point clé : ce n’est pas le code qui a régressé, c’est la barre de qualité qui est montée — sous l’effet de la relecture assistée par LLM, devenue plus efficace pendant que la version 19 était déjà écrite.

Un projet réputé pour sa prudence, pris de court

PostgreSQL n’est pas un projet qui improvise. Proposé par Michael Stonebraker en 1986, converti au SQL en 1994, libéré sous licence permissive en 1995, il est devenu la base de données la plus populaire chez les développeurs professionnels, portée par les trois hyperscalers et une galaxie de systèmes distribués compatibles. Sa réputation repose sur un cycle de commitfest rigoureux et une aversion assumée pour les sorties précipitées.

C’est précisément ce qui rend le report de la version 19 notable. D’ordinaire, un retard de PostgreSQL vient d’un défaut bloquant. Cette fois, il vient du contraire : trop de défauts ont été trouvés, trop tard dans le cycle pour être absorbés proprement.

La barre de qualité a monté en plein vol

Le mécanisme est contre-intuitif. Les grandes nouveautés de PostgreSQL 19 ont été rédigées à une époque où la relecture assistée par IA était encore peu utile. Dans les mois qui ont précédé la sortie, ces outils sont devenus plus performants, et ils ont fait remonter une longue traîne de défauts que l’équipe n’avait pas anticipée.

Peter Eisentraut, vice-président d’EDB et committer de premier plan, décrit le phénomène dans son billet : la relecture LLM a mis au jour « une longue traîne de problèmes relativement bénins touchant des cas limites », que l’on aurait découverts plus tard, probablement étalés sur les cinq années suivant la sortie. « Avec la relecture assistée par LLM, ces choses sont trouvées beaucoup plus vite, et vous vous retrouvez face à une liste de quarante rapports de défauts. Même si chacun ne demande en moyenne qu’un correctif de trois lignes, il y a un coût fixe à traiter chacun d’eux, et vous finissez par manquer de temps. »

Autrement dit : les correctifs sont triviaux, mais le traitement de quarante rapports — trier, reproduire, valider, documenter — dépasse ce qu’un cycle de beta peut absorber. Certains défauts « significatifs » étaient en outre de vrais problèmes architecturaux, impossibles à réparer « rapidement et pendant la beta ». Eisentraut formule la conclusion avec une franchise rare : « la barre de qualité effective a été relevée après que la fonctionnalité a été écrite et committée. »

Il tient aussi à écarter un contresens : les reverts ne viennent pas du vibe coding. Cette pratique n’était pas disponible quand la plupart des nouveautés ont été écrites. C’est l’outil de relecture qui a progressé, pas la discipline d’écriture qui a baissé.

Huit à dix fonctionnalités renvoyées à la version 20

Le retrait le plus emblématique est celui de SQL/PGQ, les requêtes de graphe par propriété entrées dans le standard SQL en 2023. Cette syntaxe permet d’explorer des relations entre nœuds reliés par des arêtes, et l’implémentation de PostgreSQL a été retirée pour des questions non résolues.

Le contributeur Tom Lane avait prévenu dès le 15 septembre 2026 : « À ce stade, je parierais un dîner que si nous l’expédions dans la v19, il y aura des bugs découverts après la sortie, impossibles à corriger avant la v20. » La décision de retrait lui donne raison — et illustre le coût d’un défaut architectural détecté trop tard : un bug « incassable » sans nouvelle version majeure.

Au total, huit à dix fonctionnalités sont repoussées. Elles devraient atterrir dans PostgreSQL 20, une version que l’équipe imaginait il y a encore quelques mois comme un simple correctif sans nouveauté. Elle portera finalement les fonctionnalités laissées de côté — un glissement de calendrier qui se propage à tout l’écosystème des clients, extensions et cloud providers qui calent leurs roadmaps sur celles du projet amont.

Ce que la version 19 garde quand même

Le report ne vide pas la version. PostgreSQL 19 conservera notamment REPACK CONCURRENTLY, qui évite le verrouillage de table de l’opération VACUUM FULL utilisée pour récupérer de l’espace disque. C’est un gain réel pour les bases en production, où un VACUUM FULL peut geler une table pendant des heures.

Eisentraut promet une version 19 « très robuste, après toute cette surveillance supplémentaire ». Le message de fond est assumé : un cycle plus long avec une barre plus haute vaut mieux qu’une sortie ponctuelle suivie de cinq ans de correctifs. Pour un SRE ou un DBA, cette robustesse supplémentaire est une raison de ne pas retarder l’upgrade une fois la 19 sortie — contrairement au réflexe habituel d’attendre le premier correctif mineur.

Le signal dépasse PostgreSQL

Ce qui se joue ici n’est pas propre à PostgreSQL. Le noyau Linux débat depuis des semaines du tag « Assisted-by: » qui documente l’usage d’un LLM dans un patch, et envisage de l’abandonner tant la pratique s’est banalisée ; Linus Torvalds a lui-même publié un premier patch assisté par IA après avoir fixé des règles claires. Dans le même temps, les mainteneurs de projets open source décrivent une boîte de réception envahie de contributions de faible qualité générées par IA — « AI cuts coding time, but it’s also filling open source’s inbox with crap », titrait The Register le 21 octobre.

PostgreSQL 19 ajoute une pièce à ce puzzle : la relecture IA ne se contente pas de trier les contributions, elle rehausse la barre interne d’un projet mature au point d’en décaler la sortie. C’est un signal fort pour toutes les équipes qui mesurent leur « vélocité » sans mesurer leur capacité d’absorption.

Verdict

Si vous intégrez la relecture LLM dans votre pipeline, budgétez explicitement la taxe de revert. Le cas PostgreSQL montre que l’outil n’échoue pas quand il trouve des bugs : il réussit, et c’est la capacité d’absorption de l’équipe qui devient le goulot. Prévoyez un temps fixe par rapport de défaut, et assumez que la barre de qualité montera après que le code a été écrit — donc que des fonctionnalités déjà validées pourront être décalées d’une version. Si vous démarrez un cycle avec une relecture IA nouvelle, traitez le premier cycle comme un cycle de rattrapage, pas comme un cycle nominal.

Si vous gérez des bases PostgreSQL en production, ne changez rien à vos plans d’upgrade pour l’instant : la 19 n’est pas sortie, et rien n’indique un problème de sécurité à corriger en urgence. Notez simplement deux choses. D’abord, la sortie glisse vers le 19 novembre 2026 ; ajustez vos fenêtres de mise à niveau en conséquence. Ensuite, préparez-vous à une version 20 plus chargée que prévu : les fonctionnalités reportées — dont SQL/PGQ — y arriveront, et les équipes qui suivent les requêtes de graphe ont tout intérêt à tester la syntaxe dès les premières beta.

Références

• The Register — Postgres 19 delayed after AI reviewers find more bugs than humans can fix
• Peter Eisentraut — The reverts will continue until morale improves
• The Register — PostgreSQL 19 graph queries fail the « would you ship this » test
• The Register — AI cuts coding time, but it’s also filling open source’s inbox with crap