Databricks erläutert Lakebase-Branching für parallele Codierungs‑Agenten

Databricks hat am 8. Oktober 2026 einen Blogbeitrag veröffentlicht, der einen Entwicklungs‑Workflow beschreibt, bei dem jeder parallele Codierungs‑Agent und jeder Pull‑Request gegen seine eigene isolierte, flüchtige Postgres‑Datenbank läuft, die durch das Copy‑on‑Write‑Branching im Lakebase-Datenbankservice erstellt wird.

Im Beitrag beschreibt Databricks die Datenbank als einen oft übersehenen Teil des Entwicklungs‑Workflows zu einem Zeitpunkt, an dem Codierungs‑Agenten einen wachsenden Anteil der Entwicklungsarbeit übernehmen und das gleichzeitige Ausführen mehrerer Agenten zur Norm wird. In traditionellen gemeinsam genutzten Umgebungen, etwa einer einzigen Entwicklungs‑ oder Staging‑Datenbank, können konkurrierende Agenten bei Schema‑Änderungen in Konflikt geraten, sich gegenseitig behindern oder auf Mock‑Daten zurückgreifen, die die Realität nicht abbilden. Laut dem Beitrag waren dies bereits Schmerzpunkte für Entwickler, doch Agenten verschärfen sie, weil sie schneller arbeiten, parallel operieren und eine sichere Umgebung benötigen, die verhindert, dass Produktionsdaten gefährdet oder sensible Daten offengelegt werden.

Branching-Mechanik

Databricks sagt, dass Lakebase‑Branching es einem Benutzer ermöglicht, eine komplette Datenbank in weniger als einer Sekunde zu verzweigen, unabhängig von ihrer Größe. Zweige basieren auf Copy‑on‑Write‑Speicher: Ein neuer Zweig erbt das Schema und die Daten seines Elternteils, während er den zugrunde liegenden Speicher teilt und zusätzlichen Speicher nur bei Abweichungen verbraucht. Laut Databricks’ Lakebase-Branching-Dokumentation wird jedes Projekt mit einem Standardzweig namens production erstellt, und jeder Zweig außer dem Wurzelzweig hat ein übergeordnetes Element. Änderungen in einem Kindzweig wirken sich nie auf den Elternzweig aus, und die Isolation erstreckt sich auf den Postgres‑Rollen‑Zustand: Rollen und Datenbanken, die erstellt wurden, GRANT‑ und REVOKE‑Anweisungen, sowie Rollenattribute, die in einem Zweig geändert werden, haben keine Wirkung auf andere Zweige.

Jeder Zweig verfügt über eigene Compute‑Ressourcen, skaliert im Leerlauf auf Null und wird laut Dokumentation nur für aktive Compute‑Stunden abgerechnet. Die Speicher‑Abrechnung hängt davon ab, ob ein Zweig ein Verfallsdatum hat: Ein verfallender Zweig wird nur für die darauf geänderten Daten berechnet, während ein permanenter Zweig ohne Verfall für seine gesamte Datenmenge abgerechnet wird, ähnlich einer eigenständigen Datenbank. Ein Zweig‑Reset, der einen Kindzweig vom Elternzweig aktualisiert, funktioniert nur in eine Richtung, von Eltern zu Kind. Die zeitpunktbezogene Wiederherstellung erzeugt einen neuen Wurzelzweig aus historischen Daten innerhalb des Wiederherstellungsfensters, während der ursprüngliche Zweig unverändert und betriebsbereit bleibt.

Auf seiner Produktseite beschreibt Databricks Lakebase als einen vollständig verwalteten, serverlosen Postgres‑Service, der die Open‑Source‑Postgres‑Engine ausführt und keinen Fork verwendet.

Ein Zweig pro Agent

Der im Beitrag beschriebene Workflow kombiniert Git‑Worktrees mit Lakebase‑Zweigen. Ein Worktree stellt jedem Agenten ein eigenes Verzeichnis mit einem ausgecheckten Zweig zur Verfügung, wodurch Dateikonflikte zwischen den Agenten vermieden werden, und ein Post‑Checkout‑Hook erstellt dann automatisch einen Datenbankzweig für jeden neuen Worktree. Im Beispiel, das mit Claude Code erstellt wurde, führt ein Agent aus claude -worktree feature-123, Git erstellt den Worktree, der Hook wird ausgelöst, und der Agent erhält sein eigenes Code‑Verzeichnis sowie eine vollständig isolierte Datenbank. Repository‑Anleitungsdateien wie AGENTS.md oder CLAUDE.md steuern das Verhalten des Agenten, und wenn der Agent fertig ist, öffnet er einen Pull‑Request, wonach sowohl der Worktree als auch der Datenbankzweig stillgelegt werden können.

Ein Unterschied zu Git, so der Beitrag, besteht darin, dass Lakebase‑Zweige nicht zurück in den Hauptzweig gemergt werden, weil Eltern‑ und Kindzweig unabhängig voneinander Änderungen vornehmen können und deren Datenabgleich schnell unpraktisch werden kann. Stattdessen werden Schema‑Änderungen im Code zusammen mit der Anwendungslogik nachverfolgt und über Migrationen in den Elternzweig übernommen, wobei Werkzeuge wie Drizzle, Flyway, Liquibase oder Alembic zum Einsatz kommen. Das Beispiel nutzt Drizzle: Wenn eine Schema‑Änderung erforderlich ist, fügt der Agent die entsprechende Migration zum Code‑Repository hinzu, und die Bereitstellungs‑Automatisierung wendet sie beim Deployen der Vorschau‑Anwendung an und erneut, wenn die Änderung in den Hauptzweig gemergt wird.

Ein Zweig pro Pull‑Request

Für die kontinuierliche Integration skizziert der Beitrag einen GitHub‑Actions‑Workflow, bei dem das Öffnen eines Pull‑Requests gegen den Hauptzweig die Lakebase‑CLI auslöst, einen flüchtigen Zweig zu erstellen, der nach dem Pull‑Request benannt wird und ein Kind des production‑Zweigs ist; dieser Zweig wird dann zur Datenbankumgebung des Pull‑Requests. Das Migrationstool wird gegen den neuen Zweig ausgeführt, eine Vorschau‑Anwendung wird bereitgestellt und auf die Verbindungszeichenfolge des Zweigs gerichtet, und ein Schema‑Diff wird erzeugt und als Pull‑Request‑Kommentar veröffentlicht, der exakt zeigt, welche Tabellen, Spalten oder Indizes geändert wurden. Wird der Pull‑Request geschlossen oder gemergt, löscht die Automatisierung den Zweig. Da der Zweig von production ausgeht, kann die Schema‑Migration angewendet und getestet werden, bevor die Änderung in die Produktion gelangt. Das Beispiel stellt Vorschauen auf Databricks Apps bereit, obwohl der Beitrag erklärt, dass das Konzept auch auf anderen Hosting‑Plattformen wie Vercel, Netlify und Cloudflare anwendbar ist.

Bezüglich Umgebungen stellt der Beitrag fest, dass ein gängiges Lakebase‑Setup ein Databricks‑Workspace pro Umgebung verwendet, etwa Entwicklung, Staging und Produktion, und dass Teams häufig von einer vorbefüllten Datenbank statt von der Produktionsdatenbank aus verzweigen, um die Offenlegung sensibler Daten wie PII zu vermeiden. Die Anleitung nutzt aus Gründen der Einfachheit ein einzelnes Workspace, weist jedoch darauf hin, dass dieselben Konzepte auch für Multi‑Workspace‑Setups gelten.

Fehlerreproduktion und Migrationstests

Jenseits der per‑Agent‑ und per‑Pull‑Request‑Schleifen beschreibt der Beitrag Verzweigungs‑Workflows, die im Beispiel‑Repository nicht implementiert sind. Ein Entwickler kann zu einem bestimmten Zeitpunkt, typischerweise kurz bevor ein Fehler aufgetreten ist, einen isolierten Branch von der Produktion aus erstellen, das Problem mit realen Daten reproduzieren und untersuchen und den Branch wieder entfernen, sobald ein Fix validiert wurde. Teams können zudem einen Branch erstellen, bevor sie in die Produktion deployen, eine Schema‑Migration anwenden, Tests ausführen und überprüfen, ob die Anwendung weiterhin wie erwartet funktioniert, bevor die Änderung promoted wird. Diese Workflows ermöglichen es Entwicklern, mit produktionsähnlichen oder aus der Produktion abgeleiteten Daten zu arbeiten, zum Beispiel mithilfe von Unity Catalog‑Maskierung, ohne die Live‑Datenbank zu gefährden, so der Beitrag.

Der Beitrag verweist auf ein Beispiel‑Repository auf GitHub, im Verzeichnis Lakebase‑Agentic‑CI des databricks/tmm‑Repositories, das Beispiele für GitHub‑Actions‑Workflows enthält, die das Muster implementieren. Er schlussfolgert, dass diese Muster zusammen das bilden, was er die Lakebase‑Entwicklungsschleife nennt: ein Branch pro Agent, ein Branch pro Pull‑Request und isolierte Branches für die Produktionsvalidierung.