Le « database branching » a un problème de branding.
Pendant des années, cela voulait généralement dire l’une de ces trois choses :
Un marathon dump/restore qui se termine quelque part entre votre prochain stand-up et la mort thermique de l’univers.
L’illusion d’un schéma par branche, où tout le monde fait semblant d’être « isolé » pendant que la contention sur les verrous et les conflits d’extensions montent sur le ring.
Une fonction « clone » qui signifie en réalité : « on a copié la prod, merci de ne pas demander le montant de la facture ».
Donc oui : le database branching est mort. Du moins, la version qui donne envie aux développeurs de détester la vie et aux équipes plateforme de détester les développeurs.
Mais l’idée, elle, n’a jamais été aussi vivante. Elle est simplement en train de changer de niveau. Le prochain opérateur de votre base de données ne sera pas une personne. Ce sera un agent qui enquête sur des incidents, valide des migrations, propose des changements de schéma, ajuste des index, lance des expériences de performance, puis demande poliment la permission de recommencer cinq minutes plus tard.
L’avenir, ce sont les agents, la CI, les environnements de preview, l’automatisation QA, les sandboxes analytics et l’itération rapide, avec des bases créées en permanence et à la demande, sans devoir implorer l’équipe plateforme.
Si votre infrastructure ne supporte pas cette boucle, vous n’avez pas de « workflows agentiques ». Vous avez juste un chatbot sophistiqué qui ouvre des tickets. Et les tickets ne sont pas une control plane.
Ce monde a besoin de branching. Mais d’un branching qui ne soit pas un mensonge.
C’est là que Vela arrive avec un message très simple : le même Postgres, mais une autre expérience. Et surtout : un autre branching.
Le problème n’est pas PostgreSQL. C’est le workflow autour.
PostgreSQL est déjà la vedette de cette histoire. Éprouvé, extensible, validé en production et ennuyeux dans le meilleur sens du terme.
Ce qui n’a rien d’ennuyeux, en revanche, c’est à quel point tout le reste autour de Postgres reste pénible :
Vous voulez une base propre pour une feature ? Ticket.
Vous voulez des données réalistes pour un test ? Coordination, validations et rituel en trois étapes avec un dump et votre dignité.
Vous voulez tester une migration sans risque ? Bonne chance pour négocier un staging partagé que tout le monde a peur de toucher.
Le moteur va très bien. Le bug, c’est l’expérience humaine, et désormais agentique, autour de lui.
Qu’on soit clair : je connais Docker, je l’utilise souvent pour le développement et les tests unitaires. Mais repartir de zéro, injecter des seed data et espérer qu’elles couvrent réellement les cas limites de la production, ce n’est pas une bonne expérience.
Aujourd’hui, « branching » veut souvent dire « faux isolement »
La plupart des solutions de database branching tombent dans le même piège : elles optimisent pour « ressemble à une branche » au lieu de « se comporte comme une branche ».
Pour moi, le pire exemple est l’approche un schéma = une branche. Au départ, c’est tentant : c’est peu coûteux et ça tient dans une seule instance PostgreSQL. Mais la liste des effets secondaires est maudite :
Contention de verrous entre branches, parce qu’au fond c’est toujours le même serveur.
Conflits d’extensions, parce qu’on ne peut pas laisser chaque branche tout installer et tout configurer indépendamment.
Problèmes de noisy neighbor, parce que tout le monde partage le même budget CPU, mémoire et I/O. Un isolement basé sur « faites attention » n’est pas un modèle de sécurité. C’est une prière.
Et surtout : ce n’est pas un vrai clone. C’est juste une manière « relativement sûre » de tester quelques changements de schéma, jusqu’au moment où vous lancez quelque chose sur le mauvais schéma. Les permissions peuvent aider, mais essayez donc de chercher « how do I restrict a user to a specific Postgres schema ».
Ce genre de branching, c’est comme installer des cloisons dans un open space et appeler ça un « bureau privé ». En pratique, quelqu’un mange toujours du thon au poste d’à côté.
Ce que Vela fait différemment : les branches sont de vraies bases
Voici la phrase qui change tout :
Dans Vela, les branches sont de vraies bases PostgreSQL. Pas des schémas. Pas des namespaces simulés. Pas des « copies logiques ». De vraies instances Postgres.
Chaque branche tourne comme une instance Postgres complètement isolée dans sa propre micro machine virtuelle, avec des limites de ressources et des frontières de tenant qui ne reposent pas sur la bonne volonté.
Cela élimine immédiatement toute la famille de problèmes qui rend le branching traditionnel si fragile :
- Une branche ne peut pas affamer les autres.
- Une branche n’entre pas en collision avec les extensions des autres.
- Une branche ne partage pas de catastrophe de verrouillage avec sa voisine.
- Une branche ne « fuit » pas de comportement, puisqu’elle ne partage pas de processus.
- Une branche ne peut pas détruire accidentellement les données des autres branches.
Pour les équipes, c’est la différence entre « une démo sympa » et « la manière dont on teste et livre notre logiciel ».
Vela n’est pas une nouvelle base de données, et c’est précisément le but
Disons-le franchement : Vela n’est pas un moteur de base de données supplémentaire.
Il n’invente pas un nouveau langage de requête.
Il ne place pas une couche d’abstraction propriétaire entre vous et SQL.
Ce n’est pas un fork de Postgres dont le chemin de mise à jour finit en larmes.
Vela utilise Postgres upstream, donc votre outillage continue de fonctionner : ORM, outils de migration, drivers, outils BI, scripts, et même cet étrange outil interne écrit en 2017 que personne n’a le droit de toucher.
C’est important, parce qu’au moment où votre « plateforme de branching » vous force à tout replatformer, ce n’est plus du branching. C’est une reconversion.
Le contexte est roi, pour les humains comme pour les agents
L’ancien workflow base de données part du principe que les humains vont tolérer les frictions.
- « Ouvre un ticket. »
- « Attends. »
- « Coordonne-toi. »
- « Fais attention. »
- « On nettoiera plus tard. »
Les agents ne toléreront pas ça. La CI non plus. Les cycles produit rapides non plus.
La plupart des équipes vivent avec un zoo d’environnements prod, staging et dev/QA. Ça « marche » tant que les rafraîchissements sont rares et que tout le monde accepte la dérive. Avec les agents, ce modèle atteint une limite nette.
Si votre workflow ne peut pas créer rapidement des environnements de base de données sûrs, isolés et réalistes, il devient le goulot d’étranglement. Et la partie la plus coûteuse n’est pas le compute requis, mais la vitesse d’itération perdue.
La raison est simple : votre staging dérive naturellement de la prod. Les distributions de données divergent. Les extensions diffèrent. Les comportements de performance mutent. Les humains compensent avec de la connaissance tacite et du flair. Les agents n’ont pas de flair. Ils ont des entrées.
Si un agent valide une migration sur des données obsolètes ou irréalistes, il peut produire une sortie qui paraît rationnelle mais qui échoue sous les distributions de production. Ce n’est pas un problème de LLM. Ce n’est pas un problème humain. C’est un problème de contexte. Et les problèmes de contexte ne se règlent pas avec de « meilleurs prompts ».
Le modèle de Vela repose sur le self-service, la vraie isolation, le branching rapide et la suppression facile. Vela transforme les workflows base de données en quelque chose que les équipes peuvent réellement exploiter au rythme moderne. Les développeurs testent les migrations sans risquer le staging partagé. La QA valide des features sans conflit de planning. Les analystes exécutent des requêtes lourdes sans mettre la production sous assistance respiratoire. Et vos agents peuvent automatiquement valider et recommander des changements sérieux.
Et les équipes plateforme obtiennent enfin ce qu’elles veulent vraiment : de la prévisibilité, de vraies frontières de tenant et la possibilité de dire « oui » sans devoir ensuite être d’astreinte pour les expériences de tout le monde.
Le vrai tour de magie : le stockage rend le branching abordable
« Une vraie base par branche » semble coûteux, jusqu’à ce qu’on comprenne que Vela ne copie pas naïvement des téraoctets à chaque fois.
Dans le blueprint agent-ready “Building an Agent-Ready Postgres Data Platform”, Rob décrit l’architecture la plus adaptée à cette charge : shared-everything + copy-on-write (COW ; dans cette vidéo, j’explique ses bénéfices et son fonctionnement).
Le modèle mental est simple : les branches partagent un snapshot de base, la création de branche est rapide parce qu’elle ne crée que des métadonnées, et le surcoût de stockage reste proportionnel à ce que chaque branche modifie réellement, pas à la taille de la production.
Vela utilise simplyblock comme moteur de stockage distribué, ce qui permet une sémantique copy-on-write au niveau stockage.
C’est là que le « database branching » cesse d’être un événement spécial pour devenir une infrastructure d’usage quotidien. Comme créer une branche Git, sauf qu’il s’agit ici d’une base de données, et que les conséquences d’une erreur coûtent un peu plus cher.
Cela correspond aussi beaucoup mieux à la réalité des agents. Le travail agentique le plus utile est souvent très orienté lecture : analyser des schémas, échantillonner des distributions, valider des contraintes, lancer des plans EXPLAIN, tester des migrations. Tout cela demande un contexte de niveau production. Idéalement, une copie de production. Mais pas une copie physique complète de toutes les données de production. C’est précisément là que le COW change la donne.
L’isolation est nécessaire, mais toujours insuffisante
Les agents ont aussi besoin de frontières de permissions.
Le blueprint agent-ready est très clair : il faut du contrôle d’accès basé sur les rôles, des quotas et des politiques par environnement qui limitent là où un agent peut agir et ce qu’il peut modifier.
Parce que « une branche par tâche » est une frontière de sécurité, mais la plateforme a toujours besoin de gouvernance. Des credentials réservés à la branche, des permissions limitées à cette branche et un workflow propre de promotion ou d’abandon ne sont pas des détails optionnels. Ce sont eux qui font la différence entre « les agents accélèrent le travail » et « les agents accélèrent les incidents ».
Comme Vela traite l’isolation comme une primitive de premier ordre, le branching est construit autour de l’idée suivante : il faut pouvoir jeter un environnement sans conséquence. Vela met cela en œuvre avec des permissions, des limites de ressources et des frontières de VM.
Alors, le database branching est-il mort ?
Oui.
L’ancienne version est morte : les hacks de schéma, les rituels de dump/restore, le bouton « clone » qui multiplie en secret la facture et l’approche « fais-moi confiance, c’est isolé ».
Mais le database branching comme workflow par défaut, réel, sûr et rapide ne fait que commencer.
Le plus amusant, c’est que vous n’avez même pas besoin d’un câblage complet MCP (Model Context Protocol) ni d’un grand runtime autonome pour en tirer de la valeur dès maintenant. Que vous utilisiez déjà des agents ou que vous écriviez encore le code vous-même, une branche de base instantanée clonée depuis un gros jeu de données est exactement la manière dont j’ai toujours voulu tester des changements, valider des correctifs et sécuriser des migrations. Je n’avais jamais vraiment eu l’occasion de le faire à grande échelle. Jusqu’à maintenant.
Si vous adoptez aujourd’hui une habitude branch-first, où chaque vérification de migration, chaque enquête de performance et chaque expérience risquée se déroule sur une branche fraîche clonée depuis une base fiable, vous posez déjà les fondations pour que les agents puissent travailler en sécurité plus tard. Vous prouvez que contexte réaliste et isolation stricte peuvent coexister sans friction.
Le pari de Vela est simple : Postgres reste ennuyeux, et l’expérience cesse d’être douloureuse.
Si vous voulez voir ce qu’un Postgres branch-first donne en pratique, essayez le Vela Sandbox et créez une branche comme si vous le pensiez vraiment.