Robert Haas, committer principal de PostgreSQL, a publié le 30 octobre un billet de blog pour expliquer pourquoi la version majeure de cette année est en retard. Ces dix dernières années, les versions majeures de PostgreSQL sont toujours sorties entre la mi-septembre et la mi-octobre, mais PostgreSQL 19 devra très probablement attendre novembre, et le projet pourrait la repousser encore. La raison qu'il avance tient en une phrase :
« The short answer is that LLMs happened. » (En bref, les LLM sont arrivés.)
Haas est aujourd'hui ingénieur logiciel senior (senior staff) chez Databricks. Ce texte est son appréciation personnelle, et il ne donne pas de nouvelle date de sortie.
Trois grandes fonctionnalités retirées le dernier mois
Le gel des fonctionnalités a lieu chaque année le 8 avril, et retirer des fonctionnalités après le gel n'a rien d'inhabituel. Ce qui change cette année, c'est le moment et l'ampleur : entre le 27 août et le 15 septembre, trois fonctionnalités majeures ont été annulées les unes après les autres.
UPDATE/DELETE FOR PORTION OF- Les requêtes de graphes de propriétés en SQL (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
D'après Haas, des retraits ont lieu les autres années aussi, mais rarement aussi tard, et rarement plusieurs grosses fonctionnalités d'un coup.
Soixante pour cent de commits en plus, sans que les committers se relâchent
Il fixe chaque année la fenêtre de comptage du 8 avril au 25 septembre pour comparer le volume de corrections. L'an dernier, 724 commits sont entrés dans REL_18_STABLE ; cette année, 1169 dans REL_19_STABLE, soit une hausse de plus de 60 %. Pour la branche stable précédente, REL_17_STABLE en comptait 248 l'an dernier et REL_18_STABLE en compte 433 cette année, soit plus de 74 % de plus.
Haas ne pense pas que ces commits supplémentaires viennent d'un code écrit plus mal. Selon lui, le soin des committers est comparable à celui des années passées ; le changement se situe à l'étape de la détection : beaucoup de gens ont commencé à utiliser des LLM pour traquer les bugs de PostgreSQL et les remontent directement.
« What's different now is that it's become vastly easier to find those bugs. » (Ce qui change aujourd'hui, c'est qu'il est devenu bien plus facile de trouver ces bugs.)
Cette attribution comporte une lacune : l'historique des commits n'indique pas qui a découvert chaque bug ni avec quel outil, et l'article ne donne pas non plus la part des signalements issus de LLM. Les hausses citées sont mesurées ; le « principalement à cause des LLM » est l'observation d'un committer chevronné.
Le goulot d'étranglement, c'est la relecture humaine
Le mécanisme du retard comporte deux niveaux. Premier niveau : avec plus de bugs, les corriger prend naturellement plus de temps. Les LLM peuvent rédiger des correctifs, mais un correctif n'est pas forcément correct ni forcément conforme aux règles du projet, et un committer doit encore les relire un par un avant de les fusionner. Le second niveau est plus discret : le temps qui devait servir à examiner le contenu de la nouvelle version est absorbé par des problèmes de sécurité et des défauts des anciennes branches, si bien que la décision sur les fonctionnalités à retirer arrive elle aussi plus tard.
On peut rapprocher cela de l'expérience Firefox d'Epoch AI, menée il y a quelques jours. Epoch a mesuré le côté attaque : GLM 5.3 a servi à écrire des exploits dans la fenêtre qui s'ouvre une fois un correctif publié, pour un coût de calcul d'environ 1000 dollars par version. Haas parle du côté maintenance : la même capacité appliquée à un projet vieux de plusieurs décennies fait d'abord grimper le nombre de signalements, tandis que le nombre de personnes capables de relire le code n'augmente pas. La variable commune aux deux côtés est le coût de découverte des vulnérabilités, qui baisse plus vite que le coût de leur correction.
Cela n'est pas non plus si éloigné des équipes chinoises. Beaucoup de produits de bases de données dans le cloud sont développés à partir de PostgreSQL ; si le volume de fusions en amont augmente de soixante à soixante-dix pour cent, la charge de travail pour suivre les correctifs en aval pourrait croître en proportion. Quant à l'ampleur réelle de l'impact, aucun fournisseur n'a donné de chiffres jusqu'ici.
Quarante ans de stock, voilà la pression à long terme
Le retard en lui-même n'inquiète pas Haas. Il dit que, dans un cycle long, ce n'est pas bien long, et qu'il vient de l'exigence de qualité du projet. Il souligne aussi que le fait que l'IA trouve ces problèmes n'a pas changé son jugement sur la qualité de la base de code.
Ce qui le laisse sans repères, c'est la suite. Le projet a accumulé environ quarante ans de bugs que les humains n'avaient pas découverts, les LLM peuvent en déterrer beaucoup, et selon ses propres mots : « how are we ever going to catch up ». Désormais, chaque nouvelle fonctionnalité sera passée en revue par une IA, ce qui est une pression, mais peut aussi rendre le code plus solide. Il n'a pas proposé de solution, disant seulement que lui et beaucoup d'autres cherchent une voie.
Le jour où PostgreSQL 19 sortira vraiment dépendra des prochaines annonces de l'équipe de publication.
Sources : blog personnel de Robert Haas ; CocoLoop ; rapport public de l'expérience d'Epoch AI ; les statistiques de commits par branche suivent le périmètre donné dans l'article de Haas et n'ont pas été recalculées séparément.