Branches de base de données dans Postgres : flux de travail de style Git avec Databricks Lakebase

La base de données est le dernier goulot d’étranglement de votre flux de travail de développement

La gestion des branches de base de données est l’élément manquant dans les flux de travail de développement modernes. Toutes les autres parties de la pile ont évolué pour prendre en charge une itération rapide. Le code a Git. L’infrastructure a Terraform. Les déploiements ont des pipelines CI/CD qui s’exécutent en quelques minutes. Mais les bases de données relationnelles fonctionnent toujours comme il y a dix ans.

La plupart des équipes partagent une seule base de données de staging. Quelques jours après leur configuration, cette base de données n’est plus synchronisée avec la production. Les schémas divergent à mesure que les développeurs appliquent les migrations dans des ordres différents. Les valeurs de séquence ne correspondent plus. Les données de test s’accumulent et polluent les résultats. Quelqu’un finit par réinitialiser l’ensemble, et le cycle recommence.

La configuration d’un nouvel environnement est pire. L’approche standard consiste à exécuter pg_dump sur la production, à attendre qu’il se termine (quelques minutes à quelques heures selon la taille de la base de données), à le charger dans une nouvelle instance, à configurer l’accès, et à espérer que le résultat reflète réellement ce qui s’exécute en production. Pour une base de données de 500 Go, cela signifie une opération de copie de 500 Go, plus le calcul et le stockage nécessaires pour la maintenir en fonctionnement.

Le résultat est prévisible. Les équipes évitent de créer de nouveaux environnements car ils sont trop coûteux et trop lents. Les développeurs partagent une seule base de données de staging mutable. Les migrations sont testées sur des données obsolètes, ou pas du tout. Les déploiements de prévisualisation s’exécutent sur des fixtures vides au lieu de schémas réalistes. Les tests CI partagent l’état et produisent des résultats instables.

La base de données devient la partie de la pile que les développeurs ont peur de toucher.

Databricks Lakebase Postgres change cela avec la gestion des branches de base de données.

Ce qu’est réellement la gestion des branches de base de données

Une branche de base de données n’est pas une copie de base de données. Cette distinction est importante car elle change entièrement l’économie des environnements isolés.

Lorsque vous copiez une base de données, vous dupliquez toutes ses données et son schéma dans une nouvelle instance indépendante. Le temps et le coût augmentent linéairement avec la taille de la base de données. Chaque copie est un clone complet, et chaque clone commence à devenir obsolète dès sa création.

Une branche fonctionne différemment. Lorsque vous créez une branche dans Lakebase, vous obtenez un nouvel environnement Postgres entièrement isolé qui :

• Commence à partir du schéma et des données exacts de son parent à un moment précis
• Partage le même stockage sous-jacent au lieu de le dupliquer
• Ne écrit de nouvelles données que lorsque vous effectuez réellement des modifications

C’est ce qu’on appelle le copy-on-write. Tant que deux branches n’ont pas divergé, elles référencent les mêmes données stockées. Lorsque vous exécutez une migration, insérez des lignes ou modifiez des tables sur une branche, seules ces modifications sont écrites séparément. Tout le reste est partagé avec le parent.

Copie de base de données vs. branche de base de données

En termes pratiques, cela signifie :

• La création de branches prend quelques secondes, quelle que soit la taille de la base de données. Une base de données de 10 Go et une base de données de 2 To se branchent dans le même laps de temps.
• Le coût de stockage est proportionnel aux modifications, et non à la taille totale des données. Une branche qui modifie 50 Mo de données dans une base de données de 500 Go utilise environ 50 Mo de stockage supplémentaire.
• Chaque branche obtient sa propre chaîne de connexion Postgres et son propre point d’accès de calcul. Les branches sont entièrement isolées les unes des autres et de leur parent.
• Les branches inactives réduisent automatiquement leur calcul à zéro. Vous ne payez pour le calcul actif que lorsqu’une branche est réellement utilisée.

Les branches sont conçues pour être créées, utilisées et supprimées librement. Par les développeurs, par les pipelines CI, par les agents IA, par l’automatisation. Ce ne sont pas des environnements précieux qui doivent être entretenus. Elles sont jetables, comme les branches Git.

L’architecture qui rend la gestion des branches de base de données possible

Les bases de données Postgres gérées traditionnelles (RDS, Azure Database for PostgreSQL) lient le calcul et le stockage. Le processus de base de données et ses données résident sur la même instance, et les données sont stockées sous forme de système de fichiers mutable unique. C’est pourquoi la copie est la seule option pour créer un deuxième environnement : vous devez dupliquer le système de fichiers.

Mais une lakebase est construite différemment. Elle sépare complètement le calcul du stockage. Toutes les données sont écrites dans un moteur de stockage distribué et versionné qui enregistre chaque modification comme une nouvelle version au lieu d’écraser les données existantes. Cette architecture de type log est ce qui rend la gestion des branches de base de données possible en tant qu’élément fondamental plutôt qu’en tant que fonctionnalité superposée.

Comme le stockage est versionné, plusieurs branches peuvent référencer les mêmes données sous-jacentes sans risque de conflit. Comme le calcul est indépendant, chaque branche exécute son propre processus Postgres et évolue de manière autonome. Les branches non productives qui restent inactives sont automatiquement réduites à zéro et redémarrent en quelques millisecondes lorsqu’une connexion arrive.

Toutes les implémentations de branches de base de données ne se valent pas. Certaines plateformes créent des copies d’instances complètes et les appellent des branches. D’autres ne gèrent que le schéma, sans les données. Les branches Lakebase incluent le schéma et les données, utilisent le copy-on-write au niveau du stockage pour éviter la duplication, et fournissent un calcul indépendant et évolutif par branche. C’est ce qui rend possible la création de branches librement et à grande échelle, sans provisionner d’infrastructure supplémentaire.

Cette architecture permet également le voyage dans le temps. Comme chaque version des données est conservée dans une fenêtre de restauration configurable, vous pouvez créer une branche à partir de n’importe quel point du passé, pas seulement à partir de l’état actuel. C’est ce qui permet une récupération instantanée à un point précis dans le temps : au lieu de rejouer les journaux WAL ou de restaurer une sauvegarde, vous créez une branche au moment voulu et lisez directement à partir de celle-ci.

Ce que la gestion des branches de base de données débloque pour votre équipe

Une fois que la gestion des branches de base de données devient un élément fondamental rapide et peu coûteux au lieu d’une opération de copie coûteuse, de nouveaux flux de travail deviennent réalisables. Voici un résumé des modèles les plus courants. (Nous couvrons chacun d’eux en détail dans le prochain article de cette série.)

Une branche par développeur. Chaque ingénieur obtient son propre environnement isolé avec des données similaires à la production. Fini les interférences avec les modifications des autres dans une base de données de développement partagée. Lorsqu’une branche s’éloigne trop de la production, réinitialisez-la en une seule commande pour récupérer le dernier schéma et les dernières données. Comme les branches sont réduites à zéro lorsqu’elles sont inactives, ce modèle reste abordable même pour les grandes équipes.

Une branche par pull request. Automatisez la création de branches lorsqu’une PR s’ouvre et leur suppression lorsqu’elle est fusionnée ou fermée. Les déploiements de prévisualisation sur Vercel ou Netlify obtiennent chacun leur propre branche de base de données, de sorte que votre prévisualisation frontend est soutenue par des données réalistes et isolées. Les migrations s’exécutent sur des formes et des contraintes de données réelles, et non sur des fixtures de test vides. C’est le flux de travail que les équipes adoptent en premier, et c’est généralement celui qui les convainc d’adopter la gestion des branches de base de données dans l’ensemble.

Une branche par exécution de test. Les pipelines CI obtiennent une base de données fraîche et isolée pour chaque exécution. Aucun état résiduel des tests précédents. Aucune attente qu’une image de conteneur vide démarre, puis soit remplie de données fictives. Aucun résultat instable causé par des données partagées ou des dépendances d’ordre de test. Chaque exécution commence à partir de la même base de référence. Pour les tests qui nécessitent des données déterministes, vous pouvez créer des branches à partir d’un point fixe dans le temps ou d’un numéro de séquence de journal (LSN) spécifique.

Restauration instantanée. Créez une branche à partir de n’importe quel point dans le temps de votre fenêtre de restauration. Inspectez les tables supprimées, déboguez les migrations échouées ou auditez les données historiques, le tout sans toucher à la production. Utilisez la comparaison de schémas pour comparer l’état avant et après une modification. Exportez ce dont vous avez besoin à partir de la branche de récupération, puis supprimez-la. L’ensemble du processus prend quelques secondes, et non les heures ou les jours requis par la restauration à un instant T traditionnelle.

Environnements éphémères pour les agents d’IA. Les agents d’IA peuvent provisionner des bases de données par programme via l’API Lakebase, les utiliser pendant la durée d’une tâche et les arrêter une fois terminés. Les plateformes peuvent créer un versionnement au-dessus des instantanés : chaque action d’agent crée un point de contrôle, et les utilisateurs peuvent passer d’une version à l’autre instantanément. Si un agent exécute une mauvaise migration ou corrompt des données, la restauration est un simple appel d’API.

Mise en route

Le branchement de base de données dans Databricks Lakebase transforme votre base de données Postgres de la partie la plus lente de votre flux de travail de développement en la plus rapide.

Vous pouvez créer votre première branche en moins d’une minute à l’aide de la console, de l’interface CLI ou de l’API. Voici à quoi cela ressemble depuis l’interface CLI :

Voilà. Vous disposez maintenant d’un environnement Postgres isolé avec le schéma et les données complets de la production, prêt à être utilisé.

Si vous développez sur Postgres et que vous en avez assez de la surcharge liée à la gestion des environnements de base de données, commencez avec une seule branche de développement. Essayez ensuite une par PR. La plupart des équipes qui commencent avec un flux de travail de branchement de base de données adoptent rapidement le reste.

Databricks Lakebase est un Postgres serverless conçu pour les agents et les applications. En savoir plus sur databricks.com/product/lakebase.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original