PostgreSQL réécrit en Rust : pgrust valide 100 % des tests de régression

Le 23 juin 2026, le dépôt GitHub malisper/pgrust a tourné une page : son implémentation historique a été archivée sous la branche archive/pre-fabled-2026-06-23, remplacée par une réécriture qui vient de franchir un cap rare pour un projet de cette ampleur. Elle fait désormais correspondre la sortie de Postgres sur plus de 46 000 requêtes de la suite de tests de régression officielle, la même batterie de tests que l'équipe PostgreSQL utilise pour valider chaque nouvelle version.

Le projet s'appelle pgrust. Il est porté par le développeur connu sous le pseudonyme malisper, et son ambition tient en une phrase : réécrire PostgreSQL, l'un des systèmes de gestion de bases de données les plus utilisés au monde, en Rust. On vous explique ce que ce résultat signifie concrètement, ce qu'il ne signifie pas encore, et pourquoi ce cas d'école mérite votre attention si vous exploitez Postgres en production.

PostgreSQL en Rust, une ambition qui dépasse le simple exercice de style

PostgreSQL est écrit en C depuis sa création. Un choix qui a fait ses preuves en performance, mais qui laisse la porte ouverte aux classes de bugs mémoire (fuites, corruptions de pointeurs, accès à une zone déjà libérée) que Rust élimine par construction, grâce à son système de propriété et d'emprunt vérifié dès la compilation. Cette réécriture s'inscrit dans un mouvement plus large : ces dernières années, plusieurs briques critiques de l'infrastructure logicielle ont vu émerger des équivalents écrits en Rust, portés par la même promesse, mémoire sûre, surface d'attaque réduite, performance conservée.

pgrust est l'un des cas les plus ambitieux de cette vague, parce que Postgres n'est pas un petit utilitaire en ligne de commande : c'est un moteur transactionnel complexe, avec des décennies de comportements fins à reproduire à l'identique pour qu'une application existante continue de fonctionner sans modification.

Ce que le score de 46 000 requêtes prouve réellement

Le chiffre mis en avant par le projet n'est pas un argument marketing isolé, il vient avec une méthode. D'après la documentation du dépôt, pgrust vise la compatibilité avec Postgres 18.3 et fait correspondre la sortie attendue de Postgres sur plus de 46 000 requêtes de régression.

• Les tests utilisés sont les vrais tests de régression Postgres, vendorisés dans le dépôt (dossier vendor/postgres-18.3), pas une suite maison plus clémente.
• pgrust est compatible au niveau disque avec Postgres : il peut démarrer directement sur un répertoire de données Postgres 18.3 existant, sans conversion ni migration.

Cette seconde propriété est sans doute la plus significative pour un architecte technique. Un moteur qui relit le format disque natif de Postgres sans transformation s'engage sur la compatibilité binaire, pas seulement sur la compatibilité du langage SQL exposé en surface. Selon le dépôt, l'objectif affiché du projet est de garder le comportement de Postgres inchangé, de garder les vrais tests Postgres comme juge de paix, et de s'appuyer sur Rust et la programmation assistée par IA pour explorer des changements plus profonds côté serveur.

Ce que pgrust ne fait pas encore

La documentation du projet est explicite sur ses limites actuelles, ce qui est suffisamment rare pour être souligné :

• pgrust n'est pas prêt pour la production.
• Il n'est pas encore optimisé pour la performance.
• Les extensions procédurales existantes (PL/Python, PL/Perl, PL/Tcl) et les extensions Postgres classiques ne sont généralement pas encore compatibles. Certains modules contrib sont déjà portés, et davantage de compatibilité est annoncée au fil du temps.

Un point mérite aussi votre vigilance si vous envisagez d'y toucher un jour en contexte commercial : pgrust est distribué sous licence AGPL-3.0, une licence copyleft plus contraignante que la licence PostgreSQL d'origine, de type BSD. C'est un détail juridique qui compte autant que le langage de programmation choisi si vous réfléchissez à l'intégrer dans un produit.

La feuille de route : ce qui se prépare

Le dépôt liste une feuille de route qui donne une idée plus précise de ce que Rust doit permettre, au-delà du simple remplacement du langage :

• Un fonctionnement multithread des internals de Postgres, qui repose historiquement sur un processus par connexion.
• Un pooling de connexions intégré nativement, aujourd'hui délégué à des outils tiers dans la plupart des déploiements Postgres.
• Un meilleur support des charges de travail intensives en JSON.
• Des workflows de fork et de branchement de base de données plus rapides.
• Des expériences de stockage, y compris des designs sans VACUUM, la fameuse opération de nettoyage périodique régulièrement pointée du doigt dans les incidents documentés sur des instances Postgres en production.
• Des garde-fous d'exécution contre les mauvaises requêtes, y compris le SQL généré par IA, et moins de changements brutaux de plan d'exécution.

Deux points sautent aux yeux d'un exploitant Postgres chevronné : le pooling natif et la suppression du VACUUM sont deux sujets sur lesquels l'écosystème Postgres a construit des solutions de contournement depuis des années, faute de réponse native satisfaisante.

Comment le tester vous-même

Le projet propose plusieurs façons de mettre les mains dedans sans rien casser sur votre infrastructure existante. Une démonstration tourne directement dans le navigateur, en WebAssembly, sur pgrust.com, sans rien installer. Pour un test local rapide, un conteneur Docker suffit :

docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1

Une fois le conteneur démarré, une connexion classique avec le client psql suffit. Pour une installation depuis les sources sur Debian ou Ubuntu, le dépôt liste les dépendances nécessaires (build-essential, pkg-config, libicu-dev, libssl-dev, libldap2-dev, libpam0g-dev, le client postgresql-client-18), puis une compilation via :

cargo build --release --locked --bin postgres

Les développeurs curieux peuvent aussi rejouer la suite de régression eux-mêmes avec le script scripts/run-regression fourni dans le dépôt, en pointant la variable d'environnement PGRUST_BIN vers leur binaire compilé.

Notre lecture chez CZSyn

Chez CZSyn, nous déployons régulièrement des instances PostgreSQL pour nos clients (SaaS, e-commerce, outils métier internes), donc ce genre d'annonce nous intéresse directement, sans naïveté sur son stade de maturité.

Ce qui nous semble le plus intéressant dans pgrust n'est pas le langage Rust en lui-même, c'est la méthode : garder la suite de tests de régression officielle comme arbitre absolu de la compatibilité, plutôt que de partir d'une page blanche en promettant une compatibilité SQL approximative. C'est une discipline rare sur un projet de cette taille, et c'est ce qui rend le chiffre de 46 000 requêtes crédible plutôt que cosmétique.

Notre recommandation pour toute PME ou équipe technique française reste la même à ce stade : observez, testez en environnement de développement si le sujet vous intéresse, mais ne migrez aucune base de production vers pgrust aujourd'hui. L'absence de support des extensions procédurales, l'absence d'optimisation performance et le statut explicitement expérimental du projet sont des signaux suffisants pour écarter tout usage sérieux à court terme. La feuille de route (pooling natif, no-vacuum, garde-fous pour le SQL généré par IA) reste en revanche le bon indicateur à surveiller dans les prochains mois. En attendant, la vraie leçon pour vos propres projets critiques est méthodologique : toute réécriture d'un composant sensible gagne à s'appuyer sur une suite de tests de non-régression aussi complète et aussi proche du comportement réel que celle que Postgres a mis des décennies à construire.

Sources primaires

• Dépôt officiel, github.com/malisper/pgrust.
• Démonstration WebAssembly officielle, pgrust.com.
• malisper.me, « Rebuilding Postgres in Rust with AI », lancement original de pgrust.
• malisper.me, « The Four Horsemen Behind Thousands of Postgres Outages », feuille de route du projet.