So klonen Sie eine Terabyte-Postgres-Datenbank in zehn Sekunden

Jeder Backend-Entwickler hat mindestens einmal die Staging-Umgebung mit einer fehlgeschlagenen Migration zum Absturz gebracht oder eine schwere SQL-Abfrage auf synthetischen Daten von fünf Zeilen getestet, nur um dann eine Deadlock-Situation auf einer Tabelle in der Produktion für eine halbe Stunde zu erleben. Das Testen mit realen Datenvolumen ist immer schwierig und teuer: Eine Terabyte-Datenbank lässt sich nur schwer lokal einrichten, und das Bereithalten von zehn vollständigen Kopien in der Cloud für jeden Entwickler kostet eine Menge Geld.

Ingenieure von Postgres.ai lösen dieses Problem mit dem Database Lab Engine (DBLab) Utility. Das Projekt ermöglicht Thin-Klone von Postgres-Datenbanken jeder Größe in buchstäblich Sekunden, ohne Terabytes an Speicherplatz pro Klon zu verbrauchen.

Unter der Haube

Die gesamte Magie des Thin-Klonens basiert auf dem Copy-on-Write (CoW) Mechanismus. Standardmäßig verwendet DBLab das ZFS-Dateisystem, kann aber auch über LVM arbeiten.

Das Schema ist straightforward:

• Die Engine behält einen aktuellen Basis-Snapshot der Daten (PGDATA), synchronisiert mit der primären Datenbank über Replikation, Dumps oder physische Backups (WAL-G, pgBackRest).
• Wenn ein Entwickler oder eine CI-Pipeline eine Datenbankinstanz benötigt, erstellt DBLab einen Snapshot und startet eine isolierte Postgres-Instanz in einem Docker-Container.
• Alle Schreiboperationen gehen in eine separate CoW-Schicht. Basisdateien bleiben unverändert, deshalb dauert das Klonen von 1 TB Daten etwa 10 Sekunden und benötigt zu Beginn nur wenige Megabytes an Speicherplatz.

Sie können Dutzende solcher unabhängigen Datenbanken auf einem einzigen Server betreiben, und Entwickler können sicher DROP TABLE ausführen oder destruktive Migrationen durchführen, ohne das Risiko, etwas für ihre Kollegen zu beschädigen.

Was DBLab kann

Das Repository enthält eine Grundlage für die Automatisierung der Arbeit mit Datensnapshots:

• Datenbank-Branching. Sie können zwischen verschiedenen Branches und Zeitstempeln wechseln, Änderungen mit dem reset Befehl zurücksetzen und zu einem beliebigen gewünschten Zustand zurückkehren.
• Unterstützung für PostgreSQL Versionen 10 bis 18, einschließlich beliebter Erweiterungen wie pgvector und HypoPG.
• Integrierte Schutzmechanismen: automatische Löschung alter, ungenutzter Klone nach Timeout und Aufbewahrungsrichtlinien für Snapshots.
• Integration mit verwalteten Cloud-Datenbanken. Wenn Sie auf AWS RDS, GCP Cloud SQL oder Supabase sind, wo kein direkter Dateisystem-Zugriff besteht, kann DBLab auf einer separaten virtuellen Maschine bereitgestellt und für periodische automatische Datenaktualisierungen konfiguriert werden.
• Fertige Verwaltungsoberflächen: REST API, die dblab CLI-Konsolenanwendung und eine Weboberfläche.

Praktische Szenarien

Testen von Migrationen in CI/CD

Bevor ein Release ausgerollt wird, startet die Pipeline einen frischen Klon der echten Produktionsdatenbank, wendet die Migration an und misst die Ausführungszeit und Locks. Wenn die Migration einen exklusiven Lock auf einer großen Tabelle hält oder mit einem Fehler abbricht, signalisiert die Pipeline dies sofort. Nach dem Test wird der Klon sofort gelöscht.

Testen komplexer SQL-Abfragen und Hypothesen

Das Optimieren einer langsamen Abfrage auf einer leeren Datenbank ist sinnlos: Der Postgres-Optimizer wählt völlig unterschiedliche Ausführungspläne für 10 Zeilen gegenüber 10 Millionen Zeilen. Ein Klon in DBLab gibt Ihnen ein ehrliches EXPLAIN (ANALYZE, BUFFERS) auf Produktionsdaten ohne das Risiko, die Live-Datenbank zu überlasten.

Testen von Code von LLMs

Wenn Sie eine KI bitten, eine komplexe analytische Abfrage oder ein Datenschema zu generieren, besteht eine gute Chance, dass Sie eine Halluzination erhalten. Ein Klon bietet eine isolierte Sandbox, in der Sie den generierten Code schnell ausführen und seine Korrektheit überprüfen können.

Für wen ist dieses Projekt gedacht

Wenn Ihre Projektdatenbank nur wenige Gigabyte groß ist, ist das Einrichten einer Infrastruktur mit ZFS und DBLab wahrscheinlich Overkill – verwenden Sie einfach einen normalen Dump.

Aber wenn Postgres auf Hunderte von Gigabyte oder Terabyte angewachsen ist und Ihr Team Stunden mit der manuellen Vorbereitung von Testumgebungen verbringt und vor jeder Migration Angst hat, wird das Database Lab Engine eine Menge Nerven und Geld für Cloud-Infrastruktur sparen.

Der Quellcode der Engine ist unter der Apache 2.0 Lizenz open source. Sie können die Community-Version auf Ihrem eigenen Server nach der offiziellen Anleitung in der Dokumentation ausprobieren oder die öffentliche Demo unter demo.dblab.dev testen.