Databricks erläutert Lakebase Branching für CI/CD-Tests
Databricks hat beschrieben, wie das Copy-on-Write-Branching seiner Lakebase-Postgres-Datenbank die Bereitstellungszeit von CI/CD-Datenbanken beim Kunden Snorkel AI von über 30 Minuten auf unter 60 Sekunden verkürzt hat.
Kurze Antwort
Was hat Databricks zum Datenbank-Branching von Lakebase für CI/CD angekündigt?
Databricks zufolge nutzt die serverlose Postgres-Datenbank Lakebase ein Copy-on-Write-Branching, um für jeden CI/CD-Pull-Request in weniger als 60 Sekunden statt in über 30 Minuten eine isolierte, beschreibbare Kopie der Produktionsdaten bereitzustellen. Das zeigt eine Fallstudie mit dem Kunden Snorkel AI, der rund 100 gleichzeitige Branches auf einem etwa 2,5 Terabyte großen Datensatz verwaltet.
Das Wichtigste
- Databricks zufolge hat das Copy-on-Write-Branching von Lakebase es dem Kunden Snorkel AI ermöglicht, die Bereitstellungszeit für Datenbanken bei CI/CD-Pull-Requests von über 30 Minuten auf unter 60 Sekunden zu senken.
- Laut dem Blogbeitrag betreibt Snorkel AI etwa 100 gleichzeitige Pull-Request-Branches auf einem Produktionsdatensatz von rund 2,5 Terabyte, wobei jeder Branch für seine eigenen Änderungen nur 5 bis 10 Gigabyte an zusätzlichem Speicherplatz benötigt.
- Databricks erklärt, dass Branches Produktionsdaten durch privates Networking, Okta Single Sign-On für Entwickler und kurzlebige OAuth-Tokens für CI-Pipelines, die als Service Principals laufen, absichern.
- Branch-Expiration-Einstellungen löschen jeden Pull-Request-Branch automatisch, sobald er nicht mehr benötigt wird. Laut Databricks hält dies die Speicherkosten nahe an der Größe von Produktion plus aktiven Branches.
- Databricks zufolge lässt sich mit demselben Branching-Ansatz auch einzelnen Aufgaben von KI-Agenten eine eigene, isolierte und jederzeit verwerfbare Kopie einer Datenbank zuweisen.
Das Problem
Snorkel AI, ein Unternehmen, das Tools zur Datenaufbereitung für KI-Teams entwickelt, betreibt eine CI/CD-Pipeline auf Kubernetes, bei der jeder offene Pull Request einen eigenen, kurzlebigen Namespace zum Testen erhält. Laut Databricks wollte Snorkel Code gegen echte Daten aus seiner Produktionsdatenbank testen, einem Amazon-Aurora-PostgreSQL-Cluster – doch die Wiederherstellung einer vollständigen Kopie dieser Datenbank dauerte pro Umgebung rund 20 Minuten. Das sei, so Databricks, für einen Workflow, in dem Entwickler den ganzen Tag über Pull Requests öffnen, zu langsam gewesen. Snorkel konnte deshalb bislang nicht jedem Pull Request eine eigene Datenbankkopie zur Verfügung stellen.
Der Lakebase-Branching-Ansatz
Mit Lakebase, seiner serverlosen Postgres-Datenbank, habe Databricks Snorkel ermöglicht, von einem beliebigen Zeitpunkt aus einen neuen, isolierten und beschreibbaren Branch der Datenbank zu erstellen – ähnlich einem Git-Branch. Databricks beschreibt diese Branches als Copy-on-Write: Ein neuer Branch kopiert bei seiner Erstellung keine Daten, sondern teilt sich die Speicherseiten mit seinem übergeordneten Branch. Nur jene Seiten, die ein Branch verändert, werden als neue Speicherdaten geschrieben. Dem Blogbeitrag zufolge nutzte Snorkel den AWS Database Migration Service, um seine Aurora-Produktionsdatenbank in einen Lakebase-„Main“-Branch zu replizieren, und hielt diesen durch kontinuierliches Change Data Capture auf rund zwei Minuten Abstand zur Produktion. Laut Databricks ruft Snorkels CI-Pipeline die Lakebase-API auf, um bei jeder Öffnung eines Pull Requests einen neuen Branch von Main zu erstellen, legt dafür eine Ablaufzeit fest und löscht ihn, wenn der Pull Request geschlossen wird. Sollte dieser Bereinigungsschritt nicht ausgeführt werden, laufe der Branch laut Databricks automatisch ab, sobald seine Time-to-Live-Einstellung erreicht ist.
Sicherheitsmaßnahmen
Laut Databricks bewegen sich Produktionsdaten zwischen Aurora, Lakebase und Snorkels CI-Cluster über private Netzwerkverbindungen und nicht über das öffentliche Internet. Snorkels Entwickler authentifizieren sich dem Unternehmen zufolge über Okta Single Sign-On, das mit dem Databricks-Konto föderiert ist, während CI-Pipelines als Databricks-Service-Principals laufen, die über das Databricks SDK kurzlebige OAuth-Tokens erhalten. Postgres-Audit-Logs würden laut Databricks zu jeder Abfrage die Identität des jeweiligen Service Principals erfassen, sodass sich jede Abfrage bis zur ausführenden Pipeline zurückverfolgen lässt.
Von Databricks berichtete Ergebnisse
Databricks zufolge sank Snorkels Datenbank-Bereitstellungszeit nach der Einführung von Lakebase-Branching von über 30 Minuten auf unter 60 Sekunden; das System sei darauf ausgelegt, rund 100 gleichzeitige Pull-Request-Branches auf einem etwa 2,5 Terabyte großen Produktionsdatensatz zu unterstützen. Laut Blogbeitrag schreibt jeder Pull-Request-Branch zusätzlich zur gemeinsamen Basis etwa 5 bis 10 Gigabyte an Änderungen, und Snorkel führte das System bei 60 bis 70 Entwicklern über mehrere Teams hinweg ein. Databricks zitiert einen nicht namentlich genannten Snorkel-Entwickler mit der Aussage, frühere Jobs zum Kopieren von Daten hätten „Stunden gedauert und häufig zu Netzwerk- und anderen Engpässen mit verschiedenen CI-Plattformen geführt“; das Team habe eine Lösung benötigt, die seinen Sicherheits- und Compliance-Anforderungen für Daten entspricht, die die eigene virtuelle private Cloud verlassen.
Einsatz über CI/CD hinaus
Dasselbe Branching-Muster lasse sich laut Databricks auch auf KI-Agenten anwenden, die SQL schreiben, Migrationen ausführen oder Daten verändern: Jede Agentenaufgabe erhält einen eigenen Branch der Hauptdatenbank, sodass sie Daten lesen und schreiben kann, ohne die Produktion oder die Arbeit anderer Agenten zu beeinträchtigen. Agenten könnten dabei als Service Principals mit kurzlebigen OAuth-Tokens laufen, so das Unternehmen, und Branches ließen sich überprüfen und löschen, falls die Änderungen eines Agenten unerwünscht seien, oder automatisch über Ablaufeinstellungen bereinigen.
Quelle: Databricks-Blog, „Lakebase branching for CI/CD: lessons from 100 PR databases“, veröffentlicht am 31. Oktober 2026.
Häufige Fragen
- Was ist Lakebase-Branching?
- Databricks zufolge ermöglicht Lakebase Branching Nutzern, mit Copy-on-Write-Speicherung eine isolierte, beschreibbare Kopie einer Postgres-Datenbank zu einem beliebigen Zeitpunkt zu erstellen – ähnlich wie das Anlegen eines Git-Branch.
- Wie nutzte Snorkel AI das Lakebase-Branching?
- Laut Databricks erhält jeder offene Pull Request bei Snorkel AI einen eigenen Lakebase-Branch der produktiven Aurora-PostgreSQL-Datenbank für CI/CD-Tests – damit entfällt ein Prozess, der zuvor über 30 Minuten pro Umgebung in Anspruch nahm.
- Wie begründet Databricks, dass Lakebase-Branching die Kosten niedrig hält?
- Laut Databricks sorgt die Copy-on-Write-Speicherung dafür, dass ein Branch nur zusätzlichen Speicherplatz für die von ihm geänderten Daten belegt, während die Rechenleistung für jeden Branch im Leerlauf auf null herunterskaliert.
- Kann Lakebase-Branching auch außerhalb von CI/CD genutzt werden?
- Databricks zufolge funktioniert dasselbe Branching-Verfahren auch für KI-Agenten: Jede Agentenaufgabe erhält ihren eigenen, einweg nutzbaren Datenbank-Branch, in dem sie lesen, schreiben und Änderungen testen kann, ohne die Produktionsumgebung zu beeinträchtigen.