Principe de fonctionnement

db-branch repose sur les clones ZFS en copy‑on‑write. Un base correspond à un dataset ZFS contenant une sauvegarde initiale de MySQL ou PostgreSQL. La création d’une branche consiste à cloner instantanément le snapshot de la base ; aucune donnée n’est physiquement copiée, ce qui explique le temps de création de 0 byte transféré.

Chaque branche exécute son propre serveur de base sur un port dédié, ce qui isole les modifications. Le système conserve un historique de snapshots grâce à ZFS, permettant des checkpoints et des restaurations instantanées.

Mise en œuvre et performances

L’installation nécessite Ubuntu 24.04 LTS ou 26.04 LTS avec le paquet zfsutils-linux. Un exemple d’environnement de test utilise Multipass pour lancer une VM Ubuntu, installer db-branch et charger un petit jeu de données MySQL 8.4 :

multipass launch 24.04 --name db-branch-eval --memory 4G --disk 30G --timeout 900 \
  --cloud-init https://raw.githubusercontent.com/db-branch/db-branch/main/scripts/eval-cloud-init.yaml
multipass exec db-branch-eval -- sudo db-branch init --pool zpool

Sur un cluster de trois nœuds, les mesures publiées indiquent 0,5 s pour créer une branche PostgreSQL et 3 s pour MySQL, avec zéro octet copié. Le temps d’attente de 900 s dans la commande Multipass compense les téléchargements plus lents, notamment les 800 Mo requis pour MySQL sur arm64 contre 80 Mo sur Intel.

Gestion des branches et fonctionnalités avancées

Le CLI, l’API REST, le console web et le serveur MCP offrent une interface unifiée. Le serveur MCP autorise les agents LLM à créer, interroger et supprimer des branches, garantissant que les données de production restent intactes. Des options comme --ttl 72h automatisent la suppression après expiration, tandis que branch reset revient à l’état initial et branch checkpoint/branch restore permettent des sauvegardes instantanées.

Les mises à jour de version sont gérées par branch upgrade. En mode --check-only, le système simule la migration (par ex. MySQL 8.0 → 8.4) avant d’appliquer les changements, et crée automatiquement un checkpoint pour pouvoir revenir en arrière en cas d’échec.

Un cluster Raft partage bases, branches et paramètres entre les nœuds. ProxySQL, en option, redirige les connexions client vers la branche appropriée via le nom d’utilisateur ou un commentaire SQL /*db_branch='name'*/.

Limites et perspectives

Le pool ZFS utilisé dans les démonstrations est basé sur un fichier, ce qui le rend plus lent et inadapté à des charges de production. Les modules payants (auth/SSO, audit, historique, diff, stockage FSx) restent fermés et nécessitent une licence, ce qui peut freiner l’adoption dans les environnements strictement open‑source.

Aucun service hébergé n’est proposé ; les utilisateurs doivent gérer l’infrastructure eux‑mêmes, ce qui impose une expertise en ZFS et en orchestration de clusters. Malgré ces contraintes, la capacité à fournir des copies de bases de plusieurs dizaines de gigaoctets en quelques secondes ouvre des possibilités concrètes pour les pipelines CI/CD et les tests d’IA, où chaque pull request ou chaque scénario d’agent peut disposer d’un environnement de données isolé et jetable.