Le 9 juillet 2026, Malcolm Matis — ancien PDG de Heap et praticien de longue date de Postgres — a annoncé quelque chose qui aurait semblé satirique il y a dix-huit mois : une réécriture complète de PostgreSQL en Rust, générée en grande partie par huit agents IA, qui passe les 46 066 requêtes de la suite de régression PostgreSQL 18.3.
Pas un sous-ensemble. Pas « la plupart ». La suite entière, sans un seul échec.
Le projet s'appelle pgrust, il est sous licence AGPL-3.0, et il constitue le point de données le plus concret à ce jour dans un débat que les développeurs mènent depuis le début de l'année : les agents IA peuvent-ils réellement faire du travail système sérieux, ou produisent-ils simplement du code plausible qui s'effondre au contact du réel ?
La réponse honnête, comme souvent, se situe entre les deux — et les détails comptent énormément.
Ce qui a réellement été construit
Les chiffres méritent d'être énoncés clairement :
| Métrique | Valeur |
|---|---|
| Lignes de Rust générées | 450 000+ |
| Agents IA en parallèle | 8 (comptes Codex payants) |
| Outil de coordination | Conductor, 10 à 20 sessions parallèles |
| Coût mensuel des agents | ~1 600 $ |
| Requêtes de régression passées | 46 066 / 46 066 |
| Délai jusqu'au premier build fonctionnel | Environ trois mois |
Cette dernière ligne mérite attention. PostgreSQL représente près de trois décennies d'ingénierie accumulée. Une petite équipe dotée d'une flotte d'agents a reproduit son comportement observable dans un autre langage en un seul trimestre, pour moins que le coût mensuel d'un ingénieur junior.
La version v0.1 n'est pas un jouet. Elle parle le protocole natif de Postgres, donc psql et les pilotes clients standards s'y connectent sans modification. Elle démarre directement depuis un répertoire de données PostgreSQL 18.3 existant — sans dump, sans migration, sans conversion. Elle exécute un véritable planificateur de requêtes : EXPLAIN ANALYZE fonctionne, et les décisions index-contre-parcours-séquentiel sont réelles, pas simulées.
Vous pouvez l'essayer en une trentaine de secondes :
docker pull malisper/pgrust:v0.1
docker run -d --name pgrust-demo -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1
docker exec -it pgrust-demo psql -U postgres -h 127.0.0.1Une démo WebAssembly dans le navigateur existe également sur pgrust.com si vous préférez éviter le téléchargement d'image.
Le pari architectural
C'est ici que pgrust cesse d'être un exercice de traduction pour devenir un véritable argument d'ingénierie.
PostgreSQL utilise un modèle processus-par-connexion. Chaque connexion cliente crée un nouveau processus système. C'est la raison pour laquelle PostgreSQL est réputé gourmand en mémoire sous forte charge de connexions, et pourquoi pratiquement tout déploiement en production s'appuie sur PgBouncer ou un pooler équivalent. Ce choix date d'une époque où les threads étaient peu fiables et l'isolation par processus constituait le défaut raisonnable.
La v0.1 conserve ce modèle — logiquement, puisque l'objectif était d'abord la compatibilité. Mais la branche de développement non publiée bascule vers un modèle thread-par-connexion : la base tourne comme un processus unique, les connexions deviennent des threads légers, et la mémoire est partagée plutôt que dupliquée. Cela permet des caches partagés entre connexions et réduit fortement le besoin de pooling externe.
Les résultats annoncés pour cette branche :
- 50 % plus rapide en débit transactionnel sur Percona-TPCC
- ~300x plus rapide sur les charges analytiques
- 10x plus rapide sur les opérations regex
- Toujours 2x plus lent que ClickHouse sur ClickBench
Considérez chacun de ces chiffres comme indicatif. Ils proviennent d'une base de code non publiée et n'ont pas été reproduits indépendamment. Matis lui-même décrit prudemment la v0.1 comme ni prête pour la production, ni optimisée en performance.
Le chiffre de 300x en analytique est d'ailleurs moins magique qu'il n'y paraît. Le moteur d'exécution en lignes de PostgreSQL n'a jamais été conçu pour les balayages analytiques, et le battre sur cet axe est un gain connu et bien compris. Le résultat ClickBench — toujours à la moitié de la vitesse de ClickHouse — est le chiffre le plus informatif, car il montre pgrust à une place raisonnable face à un moteur colonnaire dédié plutôt que dans le domaine du fantasme.
Ce qui ne fonctionne pas
L'écosystème d'extensions est le mur.
pgvector, TimescaleDB, PostGIS — aucun ne fonctionne. Et pour une immense proportion des déploiements PostgreSQL réels en 2026, c'est précisément la raison pour laquelle PostgreSQL avait été choisi. Un Postgres sans pgvector n'est pas un remplacement direct pour une équipe qui construit de la génération augmentée par récupération ; c'est un produit différent qui parle le même protocole.
Cette lacune n'est pas accessoire. Les extensions PostgreSQL se lient à des API C internes, des contextes mémoire et des tables de pointeurs de fonctions qui n'ont pas d'équivalent naturel en Rust. Les supporter implique soit de réimplémenter chaque extension en Rust, soit de construire une couche de compatibilité FFI qui réintroduit une grande partie de l'insécurité mémoire que Rust devait justement éliminer. Aucune des deux options n'est un projet de week-end.
Le modèle thread-par-connexion porte également un coût réel que le tableau de benchmarks ne montre pas. Avec l'isolation par processus, un segfault dans un backend tue une connexion. Avec un modèle à mémoire partagée, une corruption mémoire dans un thread peut faire tomber toutes les connexions de l'instance. Les garanties de Rust aident considérablement ici — mais des blocs unsafe existent dans toute base de données manipulant des pages brutes, et ce code compte 450 000 lignes à auditer.
Ce qui devrait réellement changer votre réflexion
Il est tentant de classer cela sous « démo impressionnante, à ignorer jusqu'à la v2 ». Ce serait une erreur, mais la réaction inverse le serait tout autant.
L'affirmation véritablement significative n'est pas qu'une IA a écrit une base de données. C'est qu'une suite de tests exhaustive s'est révélée être une spécification suffisante pour qu'une machine réimplémente un système. La suite de régression de PostgreSQL est la paranoïa accumulée de trente ans de mainteneurs consignant chaque cas limite qui les a mordus. Ce corpus, il s'avère, est assez dense pour guider une flotte d'agents vers l'équivalence comportementale.
Cela a une implication directe pour votre propre code, et ce n'est pas celle vers laquelle la plupart se précipitent. Ce n'est pas « nous pouvons réécrire notre système legacy maintenant ». C'est : la qualité de votre suite de tests détermine désormais si la migration assistée par IA vous est seulement accessible. Un système faiblement testé ne peut pas être réécrit sereinement par des agents, car rien ne contraint la sortie. Un système doté d'une suite comportementale exhaustive, si. La couverture de tests est discrètement devenue une capacité de migration, pas seulement une tactique de prévention des défauts.
Le contrepoids est tout aussi important. Passer 46 066 requêtes de régression n'équivaut pas à être correct. Les bases en production échouent de manières que les suites de tests ne peuvent structurellement capturer : latence de réplication en cas de partition, corruption WAL après coupure, régressions du planificateur n'apparaissant qu'avec une distribution statistique particulière, contentions de verrous émergeant à un millier d'écrivains concurrents. La fiabilité de PostgreSQL vient de trois décennies de cette exposition, pas de ses fichiers de test. Reproduire les tests reproduit la spécification, pas le durcissement.
Les sceptiques ont raison sur ce point, et ils ont raison d'une manière qui ne diminue en rien l'exploit.
Faut-il agir ?
Pour des charges de production, la réponse est non, et elle le restera un certain temps. Personne ne devrait envisager pgrust pour des données réelles en 2026.
Mais trois actions méritent d'être entreprises :
Lancez l'image Docker. Pointez-la vers une copie d'un vrai répertoire de données et exécutez votre charge de requêtes réelle. Trente minutes d'expérience directe valent mieux que n'importe quel article, celui-ci compris, pour calibrer le chemin parcouru par cette technologie.
Auditez votre suite de tests comme un actif de migration. Posez une question concrète : si vous remettiez votre suite de tests et rien d'autre à un ingénieur compétent n'ayant jamais vu votre code, pourrait-il réimplémenter le système ? Partout où la réponse est non, c'est précisément là que la modernisation assistée par IA vous est inaccessible — et là où l'écart mérite d'être comblé de toute façon.
Recalibrez les estimations, prudemment. L'intuition ancienne selon laquelle une réécriture système est un engagement pluriannuel multi-équipes n'est plus fiable pour la partie génération de code. Elle reste parfaitement fiable pour la validation, le durcissement et la confiance en production — là où, comme pgrust le démontre, l'écrasante majorité du coût réel a toujours résidé.
La synthèse inconfortable
Les deux lectures populaires de pgrust sont fausses.
« L'IA peut désormais tout réécrire » est faux, car l'écart d'extensions, les benchmarks non vérifiés et le durcissement absent ne sont pas des broutilles — ils constituent la majorité du travail restant, et la partie difficile.
« Ce n'est qu'une démo sans substance » est également faux, car 46 066 requêtes de régression passées contre une base de trente ans n'était pas quelque chose que l'industrie pouvait produire à ce coût il y a six mois, et prétendre le contraire relève d'un défaut d'observation.
Ce qui a réellement changé, c'est le ratio. Écrire le code n'est plus la partie coûteuse d'une grande migration. Savoir si le code est correct l'est toujours — et les équipes qui ont investi dans ce savoir, via les tests, l'observabilité et la discipline de spécification, sont celles qui viennent d'acquérir une capacité véritablement nouvelle.
Chez Noqta, c'est le prisme que nous appliquons aux travaux de modernisation : la migration est rarement bloquée par le volume de code. Elle est bloquée par l'incapacité à prouver que le nouveau système se comporte comme l'ancien. pgrust est la démonstration la plus claire à ce jour de ce qui devient possible une fois cette preuve établie — et de tout le travail qui reste ensuite.
À lire également :