Prolly trees : versionner une base de données comme du code Git

Le 1er mai 2026, LWN.net consacrait un article détaillé à Dolt, une base de données compatible MySQL qui permet de faire un commit, une branche ou un diff sur des données SQL, exactement comme sur un dépôt Git. Le mécanisme qui rend cela possible, une variante de B-tree baptisée Prolly tree, mérite votre attention si vos données ont, elles aussi, une histoire à versionner.

Vous ne connaissez peut-être pas Dolt. C'est un projet open source sous licence Apache 2.0, porté par la société DoltHub, qui en décline la technologie en trois variantes : Dolt (compatible MySQL, le plus mature des trois), Doltgres (compatible PostgreSQL, récemment passé en beta) et DoltLite (compatible SQLite, actuellement en version 0.8.1). Les trois projets partagent le même moteur de stockage versionné et se contentent de brancher dessus l'analyseur de requêtes SQL de leur base d'origine.

Une base de données qui parle Git

Concrètement, Dolt ajoute des fonctions SQL qui reproduisent le vocabulaire de Git. Vous modifiez une table, vous l'ajoutez à la zone de staging, puis vous committez :

-- Modifier la base
INSERT INTO users VALUES (...);

-- Ajouter les changements à la zone de staging
SELECT dolt_add('users');

-- Committer
SELECT dolt_commit('-m', 'Add Joe to users');

-- Consulter le diff résultant
SELECT * FROM dolt_diff_users('HEAD~1', 'HEAD');

À tout instant, la base possède un commit HEAD courant, des changements en attente de staging, et des changements dans la zone de travail, exactement comme un dépôt Git. DoltHub résume cela d'une formule directe sur sa page d'accueil : vous savez déjà utiliser Dolt si vous connaissez Git et SQL. C'est un peu optimiste, mais l'idée tient : la prise en main est rapide si vous avez déjà ces deux bases.

Pourquoi un B-tree classique ne suffit pas

Pour comprendre l'intérêt réel de Dolt, il faut comprendre pourquoi les bases de données classiques ne peuvent pas simplement ajouter du versioning par-dessus leur moteur existant. MySQL, PostgreSQL et la plupart des bases relationnelles stockent leurs index sous forme de B-trees, des arbres équilibrés où chaque nœud contient un tableau de clés et de pointeurs, dimensionné pour tenir sur une page de stockage. Cette structure est excellente pour la recherche, le tri et le scan par plage, mais elle a un défaut pour le versioning : l'ordre dans lequel les lignes sont insérées ou supprimées influence la façon dont l'arbre se scinde et se réorganise en interne. Deux bases contenant exactement les mêmes données peuvent donc avoir deux B-trees complètement différents, ce qui rend la comparaison de deux versions coûteuse : il faut parcourir l'arbre entier pour savoir ce qui a réellement changé.

Git, lui, repose sur l'inverse : la possibilité de savoir rapidement qu'un sous-arbre n'a pas changé, en comparant simplement son hash. C'est ce qui permet des diffs compacts entre deux commits. Appliquer cette logique telle quelle à un B-tree produirait un bruit énorme, avec des nœuds internes qui semblent changer alors que les données qu'ils contiennent sont identiques.

Le Prolly tree : un B-tree qui oublie l'ordre d'insertion

La réponse de Dolt s'appelle le Prolly tree, pour probabilistic B-tree. C'est quasiment un B-tree standard, sauf que la logique de scission et de fusion des nœuds ne dépend plus de l'ordre d'insertion. Deux arbres contenant les mêmes clés et valeurs finissent toujours par avoir exactement la même structure, peu importe la façon dont on les a construits. Cette propriété se vérifie aussi au niveau de chaque sous-arbre : si une partie des données n'a pas changé entre deux versions, le sous-arbre correspondant garde le même hash, même si une ligne a été insérée puis supprimée entre-temps.

Résultat : comparer deux versions d'une base Dolt revient à comparer des hashes de sous-arbres, pas à rejouer l'intégralité des données. Et comme les sous-arbres identiques sont partagés en mémoire et sur disque entre les versions, stocker l'historique complet d'une base ne coûte pas un multiple linéaire de sa taille.

Ce que ça change concrètement pour vous

La force de Dolt n'est pas dans le simple fait de committer (une transaction classique fait déjà à peu près ça). L'intérêt apparaît dès que vous exploitez les branches et l'historique :

• Rejouer une analyse sur un état passé. Vous créez une branche pointant sur un commit ancien, vous appliquez le changement de schéma nécessaire, et vous lancez votre requête d'analyse sans toucher à la production.
• Donner une base réelle à un outil ou un agent automatisé. Un agent qui écrit du SQL, y compris un agent IA, peut travailler sur sa propre branche, avec des données réelles, sans pouvoir casser la production. Vous relisez le diff, et vous mergez seulement si tout est propre.
• Se connecter à une branche ou à un commit précis directement via la chaîne de connexion, sans changer d'outillage MySQL.

-- Connexion normale
mysql://db-server:3306/mydb

-- Connexion à une branche nommée
mysql://db-server:3306/mydb/branch-name

-- Connexion en lecture seule à un commit historique
mysql://db-server:3306/mydb/ia1ibijq8hq1llr7u85uivsi5lh3310p

Et parce que Dolt ne touche qu'à la couche de stockage, le planificateur de requêtes, la gestion des index et le reste restent ceux de MySQL, PostgreSQL ou SQLite. DoltHub annonce des performances comparables à MySQL lors de ses propres tests internes, avec la réserve habituelle sur la difficulté de faire un benchmark parfaitement représentatif.

Notre lecture chez CZSyn

Pour une application web classique (un site e-commerce, un SaaS B2B ou un outil interne), une base PostgreSQL ou MySQL couplée à un outil de migration reste le choix le plus sûr et le plus documenté. Ce n'est pas là que Dolt change la donne.

Là où la question devient sérieuse, c'est sur deux cas précis que l'on croise de plus en plus chez nos clients. D'abord, les équipes qui laissent un agent IA écrire directement en base pour automatiser des tâches : avoir une vraie branche isolée, avec merge après relecture humaine, est une manière beaucoup plus solide de sécuriser ce genre d'automatisation qu'un simple environnement de staging classique. Ensuite, les contextes où la traçabilité des changements de données compte autant que celle du code : un jeu de données de machine learning qui doit rester reproductible, ou un historique de modifications que l'on doit pouvoir justifier.

Notre réserve porte sur la maturité : Dolt lui-même semble solide, mais Doltgres sort tout juste de beta et DoltLite reste en version 0.8.1. Avant d'y confier une base de production, testez-le sur un projet interne ou un environnement secondaire, exactement comme vous le feriez pour n'importe quelle brique de stockage qui n'a pas quinze ans de production derrière elle.

Sources primaires

• LWN.net, Daroc Alden, « Version-controlled databases using Prolly trees », 1er mai 2026.
• DoltHub, site officiel.
• Dépôt officiel du projet, github.com/dolthub/dolt.
• Documentation officielle, docs.dolthub.com.