Datenbank-Branching in Postgres: Git-ähnliche Workflows mit Databricks Lakebase

Die Datenbank ist der letzte Engpass in Ihrem Entwicklungs-Workflow

Datenbank-Branching ist das fehlende Element in modernen Entwicklungs-Workflows. Jeder andere Teil des Stacks hat sich weiterentwickelt, um schnelle Iterationen zu unterstützen. Code hat Git. Infrastruktur hat Terraform. Deployments haben CI/CD-Pipelines, die in Minuten laufen. Aber relationale Datenbanken funktionieren immer noch so, wie sie vor zehn Jahren funktionierten.

Die meisten Teams teilen sich eine einzige Staging-Datenbank. Innerhalb weniger Tage nach der Einrichtung weicht diese Datenbank von der Produktion ab. Schemata divergieren, da Entwickler Migrationen in unterschiedlicher Reihenfolge anwenden. Sequenzwerte stimmen nicht mehr überein. Testdaten sammeln sich an und verfälschen die Ergebnisse. Jemand setzt schließlich alles zurück, und der Zyklus beginnt von vorne.

Das Einrichten einer neuen Umgebung ist noch schlimmer. Der Standardansatz besteht darin, pg_dump gegen die Produktion auszuführen, auf dessen Abschluss zu warten (Minuten bis Stunden, abhängig von der Datenbankgröße), es in eine neue Instanz zu laden, den Zugriff zu konfigurieren und zu hoffen, dass das Ergebnis tatsächlich das widerspiegelt, was in der Produktion läuft. Für eine 500-GB-Datenbank bedeutet dies eine 500-GB-Kopieoperation plus die Rechenleistung und den Speicher, um sie am Laufen zu halten.

Das Ergebnis ist vorhersehbar. Teams vermeiden die Erstellung neuer Umgebungen, da diese zu teuer und zu langsam sind. Entwickler teilen sich eine einzige, veränderliche Staging-Datenbank. Migrationen werden gegen veraltete Daten getestet oder gar nicht getestet. Vorschau-Deployments laufen gegen leere Fixtures anstelle von realistischen Schemata. CI-Tests teilen sich den Zustand und liefern unzuverlässige Ergebnisse.

Die Datenbank wird zum Teil des Stacks, den Entwickler zu berühren fürchten.

Databricks Lakebase Postgres ändert dies mit Datenbank-Branching.

Was Datenbank-Branching tatsächlich ist

Ein Datenbank-Branch ist keine Datenbankkopie. Dieser Unterschied ist wichtig, da er die Wirtschaftlichkeit isolierter Umgebungen vollständig verändert.

Wenn Sie eine Datenbank kopieren, duplizieren Sie alle ihre Daten und Schemata in eine neue, unabhängige Instanz. Zeit und Kosten skalieren linear mit der Größe der Datenbank. Jede Kopie ist ein vollständiger Klon, und jeder Klon beginnt, sobald er erstellt wurde, zu veralten.

Ein Branch funktioniert anders. Wenn Sie in Lakebase einen Branch erstellen, erhalten Sie eine neue, vollständig isolierte Postgres-Umgebung, die:

• Beginnt mit dem exakten Schema und den Daten ihres Elternteils zu einem bestimmten Zeitpunkt
• Teilt denselben zugrunde liegenden Speicher, anstatt ihn zu duplizieren
• Schreibt nur neue Daten, wenn Sie tatsächlich Änderungen vornehmen

Dies wird als Copy-on-Write bezeichnet. Solange zwei Branches nicht abgewichen sind, verweisen sie auf dieselben gespeicherten Daten. Wenn Sie eine Migration ausführen, Zeilen einfügen oder Tabellen in einem Branch ändern, werden nur diese Änderungen separat geschrieben. Alles andere wird mit dem Elternteil geteilt.

Datenbankkopie vs. Datenbank-Branch

Das bedeutet praktisch:

• Die Erstellung von Branches dauert Sekunden, unabhängig von der Datenbankgröße. Eine 10-GB-Datenbank und eine 2-TB-Datenbank werden in der gleichen Zeit gebranched.
• Die Speicherkosten sind proportional zu den Änderungen, nicht zur gesamten Datengröße. Ein Branch, der 50 MB Daten in einer 500-GB-Datenbank modifiziert, verbraucht etwa 50 MB zusätzlichen Speicher.
• Jeder Branch erhält seine eigene Postgres-Verbindungszeichenfolge und seinen eigenen Compute-Endpunkt. Branches sind vollständig voneinander und vom Elternteil isoliert.
• Leerlaufende Branches skalieren die Rechenleistung automatisch auf Null. Sie zahlen nur für aktive Rechenleistung, wenn ein Branch tatsächlich genutzt wird.

Branches sind so konzipiert, dass sie frei erstellt, genutzt und verworfen werden können. Von Entwicklern, von CI-Pipelines, von KI-Agenten, von Automatisierung. Es sind keine wertvollen Umgebungen, die gewartet werden müssen. Sie sind wegwerfbar, wie Git-Branches.

Die Architektur, die Datenbank-Branching ermöglicht

Traditionelles verwaltetes Postgres (RDS, Azure Database for PostgreSQL) koppelt Compute und Speicher. Der Datenbankprozess und seine Daten leben auf derselben Instanz, und die Daten werden als einzelnes, veränderliches Dateisystem gespeichert. Deshalb ist das Kopieren die einzige Option, um eine zweite Umgebung zu erstellen: Sie müssen das Dateisystem duplizieren.

Aber eine Lakebase ist anders aufgebaut. Sie trennt Compute und Speicher vollständig. Alle Daten werden in eine verteilte, versionierte Speicher-Engine geschrieben, die jede Änderung als neue Version aufzeichnet, anstatt vorhandene Daten zu überschreiben. Diese log-strukturierte Architektur macht Datenbank-Branching zu einem grundlegenden Merkmal und nicht zu einer nachträglich hinzugefügten Funktion.

Da der Speicher versioniert ist, können mehrere Branches auf dieselben zugrunde liegenden Daten verweisen, ohne Konfliktrisiko. Da der Compute unabhängig ist, führt jeder Branch seinen eigenen Postgres-Prozess aus und skaliert eigenständig. Nicht-Produktions-Branches, die im Leerlauf sind, skalieren automatisch auf Null und starten in Millisekunden neu, wenn eine Verbindung hergestellt wird.

Nicht alle Implementierungen von Datenbank-Branching sind gleich. Einige Plattformen erstellen vollständige Instanzkopien und nennen sie Branches. Andere verzweigen nur das Schema, ohne Daten. Lakebase-Branches umfassen sowohl Schema als auch Daten, verwenden Copy-on-Write auf der Speicherebene, um Duplizierung zu vermeiden, und bieten unabhängigen, autoskalierenden Compute pro Branch. Dies macht es praktikabel, Branches frei und in großem Maßstab zu erstellen, ohne zusätzliche Infrastruktur bereitzustellen.

Diese Architektur ermöglicht auch Zeitreisen. Da jede Version der Daten innerhalb eines konfigurierbaren Wiederherstellungsfensters aufbewahrt wird, können Sie einen Branch von jedem beliebigen Zeitpunkt in der Vergangenheit erstellen, nicht nur vom aktuellen Zustand. Dies ermöglicht die sofortige Wiederherstellung zu einem bestimmten Zeitpunkt: Anstatt WAL-Logs abzuspielen oder ein Backup wiederherzustellen, erstellen Sie einen Branch zum gewünschten Zeitstempel und lesen direkt daraus.

Was Datenbank-Branching für Ihr Team freischaltet

Sobald Datenbank-Branching ein schnelles, günstiges Grundmerkmal und keine teure Kopieroperation mehr ist, werden neue Workflows praktikabel. Hier ist eine Zusammenfassung der gängigsten Muster. (Wir behandeln jeden dieser Punkte im Detail im nächsten Beitrag dieser Reihe.)

Ein Branch pro Entwickler. Jeder Ingenieur erhält seine eigene isolierte Umgebung mit produktionsähnlichen Daten. Kein gegenseitiges Überschreiben von Änderungen in einer gemeinsam genutzten Entwicklungsdatenbank mehr. Wenn ein Branch zu weit von der Produktion abweicht, setzen Sie ihn mit einem einzigen Befehl zurück, um das neueste Schema und die neuesten Daten zu erhalten. Da Branches im Leerlauf auf Null skalieren, bleibt dieses Muster auch bei großen Teams erschwinglich.

Ein Branch pro Pull Request. Automatisieren Sie die Erstellung von Branches, wenn ein PR geöffnet wird, und deren Löschung, wenn er zusammengeführt oder geschlossen wird. Vorschau-Deployments auf Vercel oder Netlify erhalten jeweils einen eigenen Datenbank-Branch, sodass Ihre Frontend-Vorschau von realistischen, isolierten Daten unterstützt wird. Migrationen werden gegen echte Datenformen und -beschränkungen ausgeführt, nicht gegen leere Test-Fixtures. Dies ist der Workflow, den Teams zuerst annehmen, und er ist es, der sie dazu bringt, Datenbank-Branching generell zu übernehmen.

Ein Branch pro Testlauf. CI-Pipelines erhalten für jeden Lauf eine frische, isolierte Datenbank. Keine verbleibenden Zustände aus früheren Tests. Kein Warten, bis ein leeres Container-Image hochgefahren und dann mit gefälschten Daten gefüllt wird. Keine unzuverlässigen Ergebnisse durch gemeinsam genutzte Daten oder Abhängigkeiten von der Testreihenfolge. Jeder Lauf beginnt mit derselben Basislinie. Für Tests, die deterministische Daten erfordern, können Sie Branches von einem festen Zeitpunkt oder einer bestimmten Log Sequence Number (LSN) erstellen.

Sofortige Wiederherstellung. Erstellen Sie einen Branch von jedem Zeitpunkt innerhalb Ihres Wiederherstellungsfensters. Untersuchen Sie gelöschte Tabellen, debuggen Sie fehlgeschlagene Migrationen oder überprüfen Sie historische Daten, ohne die Produktion zu beeinträchtigen. Verwenden Sie Schema-Diffs, um den Zustand vor und nach einer Änderung zu vergleichen. Exportieren Sie, was Sie benötigen, aus dem Wiederherstellungs-Branch und löschen Sie ihn dann. Der gesamte Vorgang dauert Sekunden, nicht die Stunden oder Tage, die herkömmliche PITR erfordert.

Flüchtige Umgebungen für KI-Agenten. KI-Agenten können Datenbanken programmatisch über die Lakebase API bereitstellen, sie für die Dauer einer Aufgabe verwenden und sie bei Abschluss herunterfahren. Plattformen können Versionierung auf Snapshots aufbauen: Jede Agentenaktion erstellt einen Checkpoint, und Benutzer können sofort zwischen Versionen wechseln. Wenn ein Agent eine fehlerhafte Migration ausführt oder Daten beschädigt, ist das Zurückrollen ein einziger API-Aufruf.

Erste Schritte

Datenbank-Branching in Databricks Lakebase verwandelt Ihre Postgres-Datenbank vom langsamsten Teil Ihres Entwicklungs-Workflows in den schnellsten.

Sie können Ihren ersten Branch in weniger als einer Minute über die Konsole, CLI oder API erstellen. Hier ist, wie es von der CLI aussieht:

Das ist alles. Sie haben jetzt eine isolierte Postgres-Umgebung mit dem vollständigen Schema und den Daten aus der Produktion, bereit zur Verwendung.

Wenn Sie auf Postgres aufbauen und den Overhead der Verwaltung von Datenbankumgebungen leid sind, beginnen Sie mit einem einzigen Entwicklungs-Branch. Probieren Sie dann einen pro PR aus. Die meisten Teams, die mit einem Datenbank-Branching-Workflow beginnen, übernehmen schnell den Rest.

Databricks Lakebase ist serverless Postgres für Agenten und Apps. Erfahren Sie mehr unter databricks.com/product/lakebase.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag