Comment cloner une base de données Postgres d'un téraoctet en dix secondes

Chaque développeur backend a au moins une fois crashé un environnement de staging avec une migration ratée ou testé une lourde requête SQL sur des données synthétiques de cinq lignes, pour ensuite se retrouver avec un deadlock sur une table en production pendant une demi-heure. Tester sur des volumes de données réels est toujours difficile et coûteux : une base de données d'un téraoctet est difficile à configurer en local, et maintenir dix copies complètes dans le cloud pour chaque développeur coûte cher.

Les ingénieurs de Postgres.ai résolvent ce problème avec l'utilitaire Database Lab Engine (DBLab). Le projet permet de créer des clones légers de bases de données Postgres de toute taille en quelques secondes, sans consommer de téraoctets de disque par clone.

Sous le capot

Toute la magie du clonage léger repose sur le mécanisme Copy-on-Write (CoW). Par défaut, DBLab utilise le système de fichiers ZFS, mais peut également fonctionner via LVM.

Le schéma est simple :

• Le moteur conserve un instantané de base des données (PGDATA) à jour, synchronisé avec la base de données primaire via réplication, dumps ou sauvegardes physiques (WAL-G, pgBackRest).
• Lorsqu'un développeur ou un pipeline CI a besoin d'une instance de base de données, DBLab crée un instantané et lance un Postgres isolé dans un conteneur Docker.
• Toutes les opérations d'écriture vont dans une couche CoW séparée. Les fichiers de base restent inchangés, ce qui explique pourquoi le clonage de 1 To de données prend environ 10 secondes et ne nécessite que quelques mégaoctets d'espace disque au départ.

Vous pouvez exécuter des dizaines de ces bases de données indépendantes sur un seul serveur, et les développeurs peuvent safely exécuter DROP TABLE ou exécuter des migrations destructives sans risquer de casser quoi que ce soit pour leurs collègues.

Ce que DBLab peut faire

Le dépôt inclut une base pour automatiser le travail avec les instantanés de données :

• Branching de base de données. Vous pouvez basculer entre différentes branches et timestamps, annuler les modifications avec la commande reset, et revenir à n'importe quel état souhaité.
• Support des versions PostgreSQL 10 à 18, y compris les extensions populaires comme pgvector et HypoPG.
• Mécanismes de protection intégrés : suppression automatique des anciens clones inutilisés par timeout et politiques de rétention pour les instantanés.
• Intégration avec les bases de données cloud gérées. Si vous êtes sur AWS RDS, GCP Cloud SQL ou Supabase où il n'y a pas d'accès direct au système de fichiers, DBLab peut être déployé sur une machine virtuelle séparée et configuré pour des mises à jour automatiques périodiques des données.
• Interfaces de gestion prêtes à l'emploi : API REST, l'utilitaire console CLI dblab et une interface web.

Scénarios pratiques

Tester les migrations en CI/CD

Avant de déployer une release, le pipeline crée un clone frais de la vraie base de données de production, applique la migration et mesure le temps d'exécution ainsi que les locks. Si la migration prend un lock exclusif sur une table lourde ou échoue avec une erreur, le pipeline le signale immédiatement. Après le test, le clone est instantanément supprimé.

Tester les requêtes SQL complexes et les hypothèses

Optimiser une requête lente sur une base de données vide est inutile : le planificateur Postgres choisit des plans d'exécution complètement différents pour 10 lignes versus 10 millions de lignes. Un clone dans DBLab vous donne un EXPLAIN (ANALYZE, BUFFERS) honnête sur des données à l'échelle de production sans le risque de surcharger la base de données en direct.

Tester le code des LLMs

Si vous demandez à une IA de générer une requête analytique complexe ou un schéma de données, il y a de fortes chances que vous obteniez une hallucination. Un clone fournit un bac à sable isolé où vous pouvez exécuter rapidement le code généré et vérifier sa correctness.

À qui ce projet est destiné

Si la base de données de votre projet fait quelques gigaoctets, mettre en place une infrastructure avec ZFS et DBLab est probablement excessif—utilisez simplement un dump classique.

Mais si Postgres a atteint des centaines de gigaoctets ou des téraoctets, et que votre équipe passe des heures à préparer manuellement l'environnement de test et craint chaque migration, le Database Lab Engine vous fera économiser beaucoup de nerfs et d'argent sur l'infrastructure cloud.

Le code source du moteur est ouvert sous la licence Apache 2.0. Vous pouvez essayer la version Community sur votre propre serveur en suivant le guide officiel dans la documentation, ou tester la démo publique sur demo.dblab.dev.