Databricks détaille le branchement Lakebase pour les agents de codage parallèles

Databricks, le 8 octobre 2026, a publié un article de blog détaillant un flux de travail de développement dans lequel chaque agent de codage parallèle et chaque pull request s’exécutent sur leur propre base de données Postgres isolée et éphémère, créée grâce au branchement copy‑on‑write intégré à son service de base de données Lakebase.

Dans l’article, Databricks décrit la base de données comme une partie souvent négligée du flux de travail de développement à un moment où les agents de codage prennent une part croissante du travail de développement et où l’exécution de plusieurs agents en parallèle devient la norme. Avec les environnements partagés traditionnels, tels qu’une seule base de données de développement ou de staging, les agents concurrents peuvent entrer en conflit lors de modifications de schéma, interférer les uns avec les autres, ou recourir à des simulations qui ne reflètent pas les données du monde réel. Le texte indique que ces problèmes étaient déjà des points douloureux pour les développeurs, mais les agents les aggravent parce qu’ils se déplacent plus rapidement, fonctionnent en parallèle et nécessitent un environnement sûr qui évite de mettre en danger les données de production ou d’exposer des données sensibles.

Mécanique du branchement

Databricks indique que le branchement Lakebase permet à un utilisateur de créer une branche d’une base de données entière en moins d’une seconde, quelle que soit sa taille. Les branches reposent sur un stockage copy‑on‑write : une nouvelle branche hérite du schéma et des données de son parent tout en partageant le stockage sous‑jacent, ne consommant un espace supplémentaire que lorsqu’elle diverge. Selon la documentation du branchement Lakebase de Databricks, chaque projet est créé avec une branche par défaut nommée production, et chaque branche, à l’exception de la branche racine, possède un parent. Les modifications dans une branche enfant n’affectent jamais son parent, et l’isolation s’étend à l’état des rôles Postgres : les rôles et bases de données créés, les GRANTs et REVOKEs appliqués, ainsi que les attributs de rôle modifiés sur une branche n’ont aucun effet sur les autres branches.

Chaque branche possède sa propre capacité de calcul, se met à zéro lorsqu’elle est inactif, et n’est facturée que pour les heures de calcul actives, indique la documentation. La facturation du stockage dépend du fait qu’une branche expire : une branche expirante est facturée uniquement pour les données modifiées, tandis qu’une branche permanente sans expiration est facturée pour la taille complète de ses données, comme une base de données indépendante. Une réinitialisation de branche, qui rafraîchit une branche enfant à partir de son parent, fonctionne dans un seul sens, du parent vers l’enfant. La récupération ponctuelle crée une nouvelle branche racine à partir des données historiques dans la fenêtre de restauration tout en laissant la branche originale inchangée et opérationnelle.

Sur sa page produit, Databricks décrit Lakebase comme un service Postgres entièrement géré et sans serveur qui exécute le moteur Postgres open‑source plutôt qu’un fork.

Une branche par agent

Le flux de travail décrit dans l’article associe les worktrees Git aux branches Lakebase. Un worktree fournit à chaque agent son propre répertoire avec sa propre branche extraite, éliminant les conflits au niveau des fichiers entre les agents, et un hook post‑checkout crée automatiquement une branche de base de données pour chaque nouveau worktree. Dans l’exemple, construit avec Claude Code, un agent exécute claude -worktree feature-123, Git crée le worktree, le hook se déclenche, et l’agent se retrouve avec son propre répertoire de code et sa propre base de données entièrement isolée. Les fichiers d’instructions du dépôt tels que AGENTS.md ou CLAUDE.md guident le comportement de l’agent, et lorsque l’agent termine, il ouvre une pull request, après quoi le worktree et la branche de base de données peuvent être retirés.

Une différence avec Git, indique l’article, est que les branches Lakebase ne sont pas fusionnées dans la branche principale, car le parent et l’enfant peuvent tous deux changer indépendamment et la réconciliation de leurs données peut rapidement devenir impraticable. À la place, les modifications de schéma sont suivies dans le code aux côtés de la logique applicative et promues vers la branche parent via des migrations, en utilisant des outils tels que Drizzle, Flyway, Liquibase ou Alembic. L’exemple utilise Drizzle : lorsqu’une modification de schéma est nécessaire, l’agent ajoute la migration correspondante au code, et l’automatisation du déploiement l’applique lors du déploiement de l’application de prévisualisation et de nouveau lorsque la modification est fusionnée dans la branche principale.

Une branche par pull request

Pour l’intégration continue, l’article décrit un workflow GitHub Actions dans lequel l’ouverture d’une pull request sur la branche principale déclenche le CLI Lakebase pour créer une branche éphémère, nommée d’après la pull request, en tant qu’enfant de la branche production, et cette branche devient l’environnement de base de données de la pull request. L’outil de migration s’exécute sur la nouvelle branche, une application de prévisualisation est déployée et pointée vers la chaîne de connexion de la branche, et un diff de schéma est généré et publié comme commentaire de pull‑request indiquant exactement quelles tables, colonnes ou index ont changé. Lorsque la pull request est fermée ou fusionnée, l’automatisation supprime la branche. Parce que la branche part de la production, la migration de schéma peut être appliquée et testée avant que le changement n’atteigne la production. L’exemple déploie des prévisualisations sur Databricks Apps, bien que l’article indique que le concept s’applique à d’autres plateformes d’hébergement telles que Vercel, Netlify et Cloudflare.

Concernant les environnements, l’article indique qu’une configuration courante de Lakebase utilise un espace de travail Databricks par environnement, tel que développement, staging et production, et que les équipes créent généralement des branches à partir d’une base de données semée plutôt qu’à partir de la base de données de production afin d’éviter d’exposer des données sensibles comme les PII. La démonstration utilise un seul espace de travail pour simplifier tout en précisant que les mêmes concepts s’appliquent aux configurations multi‑espaces de travail.

Reproduction de bug et test de migration

Au‑delà des boucles par agent et par pull‑request, le post décrit des flux de travail de branchement qui ne sont pas implémentés dans le référentiel d’exemple. Un développeur peut créer une branche isolée à partir de la production à un moment précis, généralement juste avant l’apparition d’un bug, reproduire et enquêter sur le problème avec de vraies données, puis supprimer la branche une fois le correctif validé. Les équipes peuvent également créer une branche avant de déployer en production, appliquer une migration de schéma, exécuter des tests et vérifier que l’application se comporte toujours comme prévu avant de promouvoir le changement. Ces flux de travail permettent aux développeurs de travailler avec des données similaires à la production ou dérivées de la production, en utilisant par exemple le masquage Unity Catalog, sans mettre en danger la base de données en direct, indique le post.

Le post renvoie à un référentiel d’exemple sur GitHub, dans le répertoire Lakebase-Agentic-CI du dépôt databricks/tmm, qui contient des exemples de workflows GitHub Actions implémentant le modèle. Il conclut qu’ensemble ces modèles constituent ce qu’il appelle la boucle de développement Lakebase : une branche par agent, une branche par pull‑request et des branches isolées pour la validation en production.