Evolutionäre Datenbankentwicklung ermöglichen: Datenbank-Branching mit Lakebase, Fortsetzung

Diese Serie befasst sich zwanzig Jahre später erneut mit der Methodik des evolutionären Datenbankdesigns (Evolutionary Database Design). Eine wesentliche Einschränkung für „Database-Changes-as-Code“ (Datenbankänderungen als Code) waren schon immer gemeinsam genutzte Datenbankressourcen. Mit Copy-on-Write-Branching in Databricks Lakebase ist ein in einer Sekunde erstellter Branch einer Produktionsdatenbank im Terabyte-Bereich, der bei der Erstellung keinen Speicherplatz benötigt, nun eine O(1)-Operation. Damit fällt die Einschränkung weg, die Praktik Nr. 4 (Jeder bekommt seine eigene Datenbankinstanz) bisher zu einem bloßen Wunschtraum gemacht hat. In dieser Serie beschreiben die Autoren, was sich ändert, wenn diese Einschränkung wegfällt: Nicht die Methodik – diese bleibt bestehen –, sondern die Praktiken, die dadurch erst möglich werden, die automatische Governance auf Teamebene, die Weiterentwicklung der Rolle des DBA und die neuen Fähigkeiten, die KI-Agents mit ihren menschlichen Kollegen teilen.

Jen ist die Entwicklerin aus Evolutionary Database Design. In diesem Essay hat sie ein Datenbank-Refactoring durchgeführt und dabei ein inventory_code-Feld im Rahmen einer ganz normalen User Story in location_code, batch_number und serial_number aufgeteilt. Dies zeigt, dass DBAs und Entwickler erfolgreich zusammenarbeiten können, Schemata sich in kleinen Schritten weiterentwickeln lassen und Migrationen Änderungen sicher übertragen.

Die Serie knüpft zwanzig Jahre später wieder bei Jen an. Sie folgt derselben Methodik wie im Jahr 2003. Neu ist jedoch die technische Grundlage ihres Workflows, die durch die Lakebase-Architektur ermöglicht wird: Copy-on-Write-Datenbank-Branching. Dadurch werden die Praktiken, über die sie gelesen hat, auf Produktionsebene praktisch nutzbar. In den drei Teilen dieser Serie erleben wir dieselbe Jen in drei verschiedenen Dimensionen: ihr Arbeitstag (Teil 1), ihr neues Playbook (Teil 2) und ihr Team (Teil 3).

Teil 1 begleitete Jen bei der Umsetzung eines Features. Die von ihr angewandten Praktiken wurden im Essay Evolutionary Database Design von 2003 beschrieben, im Buch Refactoring Databases von 2006 erweitert und im Buch Continuous Delivery von 2010 (Kapitel 12) in die CI/CD-Pipeline integriert.

Die ursprünglichen sieben Praktiken

Der Essay von 2003 nannte sieben Praktiken. Fünf davon stießen bis 2026 bei der praktischen Anwendung an Grenzen.

1. DBAs arbeiten eng mit Entwicklern zusammen.
2. Alle Datenbank-Artefakte werden zusammen mit dem Anwendungscode versioniert.
3. Alle Datenbankänderungen sind Migrationen.
4. Jeder bekommt seine eigene Datenbankinstanz.
5. Entwickler integrieren Datenbankänderungen kontinuierlich.
6. Alle Datenbankänderungen sind Datenbank-Refactorings.
7. Entwickler können ihre Datenbanken bei Bedarf selbst aktualisieren.

Grenzen bei der praktischen Anwendung

• Praktik Nr. 1 (Zusammenarbeit mit DBAs). Jede Schemaänderung hatte potenziell schwerwiegende Auswirkungen auf die Produktion, weshalb die Überprüfung durch DBAs synchron erfolgen musste und als Freigabehürde wirkte. Die Zusammenarbeit hing stark vom Kalender des DBA ab.
• Praktik Nr. 4 (Jeder bekommt seine eigene Datenbankinstanz). Lizenzkosten, Infrastrukturkosten, Zeitaufwand für DBAs. Für die meisten Teams blieb dies ein Wunschtraum. Die meisten Teams griffen auf gemeinsam genutzte Entwicklungsdatenbanken zurück und nahmen die damit verbundenen Konflikte in Kauf.
• Praktik Nr. 5 (Kontinuierliche Integration von Datenbankänderungen). Die Continuous Delivery-Welle von 2010 brachte Migrationen in die Pipeline, allerdings wurden diese gegen gemeinsam genutzte Zieldatenbanken ausgeführt. Es fehlte eine Isolierung pro Pipeline.
• Praktik Nr. 6 (Alle Datenbankänderungen sind Refactorings). Die Anwendung jedes Refactorings erforderte Testumgebungen (Testdatenbanken), die den meisten Teams nicht auf PR-Ebene zur Verfügung standen.
• Praktik Nr. 7 (Entwickler aktualisieren bei Bedarf). Entwickler konnten Migrationen zwar bei Bedarf in gemeinsam genutzten Umgebungen ausführen, aber nicht sicher experimentieren, da ihre Versuche andere beeinträchtigt hätten.

Was sich geändert hat

Die von Databricks Lakebase eingeführte Technologie räumt die Hindernisse bei der Umsetzung der oben genannten Praktiken aus dem Weg. Databricks Lakebase ist eine verwaltete Postgres-Datenbank, die dieselbe Objektspeicherschicht (den Data Lake) nutzt, auf der auch das restliche Databricks Lakehouse läuft. Die Daten der Datenbank liegen in einem gemeinsam genutzten, dauerhaften Speicher – im Grunde S3-Buckets. Die Postgres-Engine läuft als separate Rechenschicht (Compute Layer) darüber. Rechenleistung und Speicher skalieren unabhängig voneinander. Die Engine kann bei hoher Last hochskalieren, bei sinkendem Datenverkehr herunterskalieren und bei Inaktivität auf Null herunterfahren. Lakebase ist in Unity Catalog integriert, was eine einheitliche Governance über mehrere Umgebungen hinweg ermöglicht.

Copy-on-write-Datenbank-Branching ist das, was diese entkoppelte Architektur in der Praxis skalierbar macht. Ein Branch erstellt einen neuen Zeiger auf denselben gemeinsam genutzten Speicher mit einer Abweichungsmarkierung. Bis im Branch geschrieben wird, teilt er sich alle Pages mit dem Parent-Branch. Erst wenn im Branch geschrieben wird, weichen die geänderten Pages ab; der Parent-Branch bleibt unberührt. Das Branching ist eine reine Metadaten-Operation, bei der keine Daten kopiert werden müssen. Sie ist unabhängig von der Größe des Parent-Branches in etwa einer Sekunde abgeschlossen. Die Branches speichern Daten nur in den geänderten Pages.

Wenn der technische Aufwand für einen Branch von der darin enthaltenen Datenmenge entkoppelt ist, fällt die Einschränkung von Praktik Nr. 4 (Jeder bekommt seine eigene Datenbankinstanz) weg. Branches pro Entwickler, pro PR und pro Experiment werden zur Routine. Behelfslösungen gehören der Vergangenheit an. Mocks fliegen aus der Testschleife und werden durch echte Postgres-Datenbanken auf Test-Branches ersetzt. Shared Staging ist nicht mehr der einzige Ort, an dem Schemaänderungen getestet werden können. In-Memory-Datenbank-Alternativen (H2, SQLite) verschwinden aus der Unit-Test-Ebene. Der DevOps-Aufwand für die Erstellung von Docker-basierten Containern zum Ausführen lokaler Datenbanken entfällt, und die Ticket-Warteschlangen der DBAs für die Bereitstellung schrumpfen, da Branches im Self-Service erstellt werden können.

Erst die Technologie ermöglicht diese Optimierungen der Methodik und führt die Ziele der Praktiken aus dem ursprünglichen Beitrag von 2003 zum Erfolg.

Neue Praktiken für 2026

Das Copy-on-Write-Datenbank-Branching von Lakebase hebt die bisherigen Einschränkungen der ursprünglichen Praktiken auf und ermöglicht vier weitere, die wir im Folgenden näher erläutern.

1. DBAs arbeiten eng mit Entwicklern zusammen. Da der Schema-Diff bei jedem PR gepostet wird, prüft der DBA diesen asynchron, genau wie jeder andere Code-Reviewer. Da der Bereitstellungsaufwand vernachlässigbar ist, haben DBAs nun die Kapazität, Code zu prüfen und vielleicht sogar von Anfang an gemeinsam mit den Entwicklern Lösungen zu erarbeiten, anstatt sie erst nach der Implementierung zu begutachten.
2. Alle Datenbank-Artefakte werden zusammen mit dem Anwendungscode versioniert. Der Schema-Diff, die Datenbankmigrationen und die Testergebnisse der Migrationen gehören nun fest zum Artefakt-Set.
3. Alle Datenbankänderungen sind Migrationen. Hinzu kommt eine neue Regel für die Erstellung: Idempotenz. Dadurch können alle zusammengeführten Migrationen automatisch in nachgelagerten Umgebungen wie QA, Staging und Produktion bereitgestellt werden.
4. Jeder bekommt seine eigene Datenbankinstanz. Dies ist nun auf Entwickler-, PR- und Experiment-Ebene möglich. So können Entwickler mit verschiedenen Lösungen experimentieren, anstatt sich mit der erstbesten funktionierenden Lösung zufrieden zu geben. Diese Freiheit führt zu optimalen Lösungen für den Produktivbetrieb.
5. Entwickler integrieren Datenbankänderungen kontinuierlich. Dies ist nun auf PR-Ebene möglich. Jeder PR durchläuft die CI auf seinem eigenen Branch.

Alle Datenbankänderungen sind Datenbank-Refactorings. Der Katalog von 2006 gilt nach wie vor. Branches bieten Ihnen eine einfache Testumgebung, um Refactorings in unterschiedlich großen Umgebungen auszuprobieren. Migrationen, die in Entwicklungsdatenbanken funktionierten, liefen in der Produktion fast nie performant – jetzt können Sie Migrationen in größeren Datenbanken testen, um eine hohe Performance sicherzustellen.

Entwickler können ihre Datenbanken nach Bedarf aktualisieren. "Nach Bedarf" bedeutet jetzt: innerhalb einer Sekunde, isoliert und mit produktionsnahen Daten.

Destruktives Testen als Standardoption. Der Schadensradius ist gleich null, ein Reset dauert nur eine Sekunde. Sie müssen sich keine Sorgen mehr machen, ob Ihr Test die Daten anderer beeinträchtigt, da Sie nach jedem Testlauf einfach einen neuen Branch erstellen können.

A/B-Varianten-Prototyping auf Datenbankebene. Erstellen Sie zwei Designs in parallelen Branches. Diskutieren Sie die Lösung gemeinsam mit dem größeren Team und den DBAs, präsentieren Sie die Ergebnisse und behalten Sie am Ende den Favoriten.

Mit dem integrierten Unity Catalog wird die Governance einmal eingerichtet und von allen Branches vererbt. Richtlinien werden automatisch auf jeden Branch angewendet – mehr dazu erfahren Sie in Teil 3.

Agent-as-Practitioner mit derselben Branching-Funktion. Agenten erhalten eigene Branches statt Zugriff auf die Produktion – mehr dazu erfahren Sie in Teil 3.

So läuft der Workflow in der CI ab

Die beiden Praktiken, die durch die Funktionen von Lakebase am meisten verbessert werden, sind Nr. 4 (jeder erhält seine eigene Datenbankinstanz) und Nr. 5 (Entwickler integrieren kontinuierlich Datenbankänderungen). Jetzt erhält nicht nur jeder eine eigene Datenbank, sondern jeder PR oder Branch – oder sogar mehrere Datenbanken pro Branch – lässt sich mit minimalem Kosten- und Zeitaufwand bereitstellen. Dieser Mechanismus kann mithilfe von zwei GitHub Actions-Workflow-Vorlagen automatisiert werden, die sich in jedes Projekt integrieren lassen.

Branch-Erstellung pro PR. pr.yml wird ausgelöst bei pull_request: [opened, synchronize] und erstellt ci-pr-<N>, abgezweigt vom Basis-Branch des PRs:

Derselbe Job wendet Migrationen auf den CI-Branch an und führt die Testsuite der Anwendung in einer echten Postgres-Umgebung aus. Ein vollständiges Beispiel für den Workflow finden Sie hier: pr.yml

Schema-Diff im PR gepostet. Derselbe pr.yml Job exportiert das Schema beider Branches, formatiert den Diff und postet ihn als PR-Kommentar. Dadurch kann der DBA die Überprüfung asynchron wie jeder andere Code-Reviewer durchführen (Praktik Nr. 1, neu aufgelegt):

Der DBA, der Code-Reviewer, das Team und jeder Agent, der die Migration erstellt hat, sehen dasselbe Artefakt im PR.

Branch-Bereinigung beim Merge. merge.yml löscht den CI-Pull-Request-Branch ci-pr-<N> und den verknüpften Lakebase-Branch des Feature-Branches, sobald der PR gemergt wird:

Ein vollständiges Beispiel für den Merge-Workflow finden Sie hier: merge.yml. Bei so vielen aktiven Branches lohnt sich unter Umständen ein wöchentliches Bereinigungsskript, das verwaiste und ungenutzte Branches entfernt. Ein Beispiel-Workflow ist hier zu finden: cleanup-orphans.yml. Wenn der Merge in einen gestuften („tiered“) Branch erfolgt, der z. B. für Staging oder Main/Production verwendet wird (dieses Konzept wird in Teil 3 näher erläutert), kann der Workflow so orchestriert werden, dass ein neuer Branch von dieser Stufe abgezweigt wird. So lassen sich Migrationen testen, bevor die endgültige Migration in einer Live-Umgebung angewendet wird, in der Benutzer aktiv sind und ständig Daten hinzufügen.

Zusammen sorgen diese Workflows dafür, dass jeder PR eine eigene Datenbank erhält und Branches kurzlebig sind – als feste Eigenschaften der Pipeline, nicht als Disziplin der Entwickler.

Das neue Playbook für evolutionäre Datenbankentwicklung

Praktik Nr. 1: DBAs arbeiten eng mit Entwicklern zusammen

Regel. Der DBA arbeitet während der gesamten Feature-Entwicklung mit den Entwicklern zusammen, nicht erst bei der abschließenden Freigabe. Die Zusammenarbeit erfolgt asynchron und direkt im PR, genau wie bei anderen Code-Reviewern.

Warum ist das jetzt eine dauerhafte Gewohnheit? Der Schema-Diff und die Testergebnisse der Migration werden automatisch in jedem PR bereitgestellt (siehe So läuft der Workflow in der CI ab oben). Der DBA prüft ein konkretes Artefakt nach dem eigenen Zeitplan. Da die Migration bereits in einem CI-Branch mit echten Daten ausgeführt wurde, muss der DBA die Änderung nicht mehr im Kopf simulieren.

Funktionsweise:

• Der DBA ist CODEOWNER für Pfade, die das Schema betreffen (migrations/, db/, Schema-Testverzeichnisse).
• Der DBA führt Reviews im PR asynchron durch, genau wie jeder andere Reviewer.
• Der Fokus des Reviews verlagert sich von Wird dies die Datenbank beschädigen? hin zu Ist das das richtige Design? und Wurde es richtig implementiert? Themen: Datenintegritätsregeln, Indexierungsstrategie, Design-Kohäsion, zukünftige Erweiterbarkeit, langfristige Wartbarkeit.

Anti-Pattern. Den DBA nicht in den PR-Flow einzubeziehen, obwohl relevante Artefakte zur Überprüfung vorliegen.

Die DBA-Rolle erhält zudem neue Verantwortlichkeiten bei der Richtlinienverwaltung und Governance auf Teamebene. Diese werden in Teil 3 behandelt.

Praktik Nr. 2: Alle Datenbank-Artefakte werden gemeinsam mit dem Anwendungscode versioniert

Regel. Jede SQL-Datei, jedes Migrationsskript und jeder Schema-Test befindet sich im selben Repository wie der Anwendungscode. Der Schema-Diff und die Ergebnisse der Migrationstests werden als PR-Ausgaben Teil des Artefakt-Sets.

Warum ist dies jetzt eine dauerhafte Gewohnheit? Das Branching fügt dem Set zwei neue Artefakte hinzu: den Schema-Diff pro PR und die Ergebnisse der Schema-Migrationstests pro PR. Beide werden von der CI aus dem tatsächlichen Branch-Status generiert. Beide landen als konkreter Nachweis im PR darüber, was geändert wurde und wie das Migrationsskript für die Änderung abgeschnitten hat.

Funktionsweise:

• Migrationsdateien in einem versionierten Verzeichnis (migrations/, db/migration/, alembic/versions/, framework-abhängig).
• Schema-beeinflussende Tests im Testbaum neben den Anwendungstests.
• Schema-Diff, der pro PR von der CI generiert und als PR-Kommentar gepostet wird.
• Ergebnisse der Migrationstests in der CI-Ausführungszusammenfassung und im PR-Kommentar.

Anti-Pattern. Das Generieren des Schema-Diffs außerhalb des PR-Flows (ein separates Dashboard, das der Reviewer öffnen muss). Das Artefakt muss dort liegen, wo der Review stattfindet. Da die Schemaänderungen an die Codeänderungen gebunden sind, führt das Aufbrechen dieser Abhängigkeit zu nachgelagerten Problemen bei der Bereitstellung.

Praxis Nr. 3: Alle Datenbankänderungen sind Migrationen

Regel. Keine manuellen ALTER TABLE in irgendeiner Umgebung. Jede Schemaänderung ist ein versioniertes, eingechecktes Migrationsskript. Migrationen sind idempotent.

Warum ist dies jetzt eine dauerhafte Gewohnheit? Die Regel „Migration als Artefakt“ ist seit 2003 unverändert. Neu ist die Disziplin der Idempotenz bei der Erstellung. Dieselbe Migration läuft im Laufe eines Übergangs auf vielen Branches, daher muss sie sich jedes Mal gleich verhalten. Eine Migration, die beim erneuten Anwenden fehlschlägt, ist ein Fehler.

Funktionsweise:

• Verwenden Sie Migrations-Frameworks wie flyway, liquibase, Knex, Alembic oder andere. Diese Frameworks verfolgen, welche Migrationen bereits ausgeführt wurden und welche nicht. Dies ermöglicht es dem Team, einen Befehl wie flyway migrate anzuwenden, der nur die noch nicht angewendeten Änderungen ausführt (indem die Änderungen in einer Metadatentabelle nachverfolgt werden).
• Es ist besser, irreversible Arbeit auf mehrere Migrationen aufzuteilen. Beispielsweise macht eine Migration, die in einem Rutsch neue Spalten hinzufügt und die Quellspalte löscht, ein Rollback unnötig schwer. Die Verwendung der „Expand first and contract later“-Strategie bietet viel mehr Optionen, sobald ein Bereitstellungszyklus bestätigt, dass keine aktiven Reader mehr darauf verweisen.
• Der Datenbank-Refactoring-Katalog aus dem Jahr 2006 nennt, welche Refactorings umkehrbar sind und welche nicht. Nutzen Sie ihn.

Anti-Pattern. Eine Migration, die darauf angewiesen ist, dass sich das Schema aufgrund lokaler Änderungen im Branch in einem bestimmten Zwischenzustand befindet. Die Migration muss auf jeden übergeordneten Branch, der vorherige Migrationen enthält, korrekt angewendet werden können.

Praxis Nr. 4: Jeder erhält seine eigene Datenbankinstanz

Regel. Jeder Entwickler, jeder PR, jedes Experiment und jeder Testlauf erhält einen eigenen Lakebase-Branch.

Warum ist dies jetzt eine dauerhafte Gewohnheit? Der zusätzliche Aufwand für das Erstellen von Docker-Containern, das Installieren lokaler Datenbankserver, das Erwerben von Lizenzen und das Befüllen leerer Datenbanken mit vorhandenem Schema und Testdaten ist nicht mehr erforderlich. Ein einfacher Lakebase-Befehl wie create-branch brancht eine 1-TB-Datenbank in derselben Sekunde wie eine 1-MB-Datenbank. Bei der Erstellung werden keine Daten kopiert; nur geänderte Seiten verbrauchen Speicherplatz. Instanzen pro Entwickler, pro PR und pro Experiment sind an der Tagesordnung.

Funktionsweise:

• Branches pro Entwickler: Erstellt nach Bedarf über databricks postgres create-branch oder den Branch-Erstellungs-Flow der SCM-Erweiterung.
• Branches pro PR: Automatisch von der CI beim Öffnen des PR erstellt (pr.yml), beim Merge oder Schließen gelöscht (merge.yml). Siehe Wie der Workflow in der CI abläuft oben für die PR- und Merge- Snippets.
• Branches pro Experiment: Abgezweigt von Staging oder Produktion zur Design-Exploration; nach dem Experiment verworfen.

Anti-Pattern. Das Teilen einer Entwicklungsdatenbank im Team „aus Bequemlichkeit“. Die in Teil 1 erwähnte, durch Konflikte verursachte Serialisierung kehrt in dem Moment zurück, in dem die Branches zusammengeführt werden.

Wo Jens Beispiel anknüpft. Ihr entwicklerspezifischer Branch wurde zu Beginn des Features von Staging abgezweigt. Der CI-Branch wurde beim Öffnen des PR von Staging abgezweigt. Ihre A/B-Explorations-Branches (Praxis Nr. 9) wurden parallel von Staging abgezweigt. Vier Branches für ein einziges Feature, alle in Sekundenschnelle, alle isoliert.

Praxis Nr. 5: Entwickler integrieren Datenbankänderungen kontinuierlich

Regel. Jeder PR läuft durch die CI gegen einen frischen Lakebase-Branch, wobei Migrationen angewendet und Tests gegen ein echtes Postgres ausgeführt werden.

Warum ist dies jetzt eine dauerhafte Gewohnheit? Die CI-Pipeline verfügt seit 2010 über eine Migrationsdisziplin. Neu ist die Isolation pro Pipeline: Jeder PR erhält seinen eigenen Branch, sodass die Integration ohne Konflikte auf realen Datenstrukturen läuft.

Funktionsweise:

• Die CI erstellt beim Öffnen des PR einen Branch. Siehe Wie der Workflow in der CI abläuft oben für das PR-Snippet.
• Migrationen werden über lakebase-migrate apply auf den Branch angewendet.
• Anwendungstests laufen über das ORM gegen den migrierten Branch, ohne Mocks.
• Schema-Diff wird im PR gepostet.
• Branch wird beim Merge oder Schließen gelöscht.

Anti-Pattern. Ausführen der PR-Validierung gegen ein gemeinsam genutztes Staging. Die Serialisierung kehrt zurück; die Isolationseigenschaft pro PR geht verloren.

Praxis Nr. 6: Alle Datenbankänderungen sind Datenbank-Refactorings

Regel. Schemaänderungen folgen benannten Refactoring-Mustern: Spalte aufteilen, Spalte umbenennen, Spalte verschieben, Typ ersetzen usw. Jedes Muster hat eine explizite Übergangsmechanik (alt und neu parallel beibehalten, aus altem befüllen, Reader austauschen, altes verwerfen).

Warum ist dies jetzt eine dauerhafte Gewohnheit? Der Katalog von 2006 auf databaserefactoring.com nennt über 70 Refactorings mit ausgearbeiteten Beispielen. Neu im Jahr 2026 ist ein kostengünstiger Ort, um die Übergangsmechanik zu erproben: Ein Entwickler-Branch nimmt den Probelauf auf; der CI-Branch verifiziert; die Produktion sieht nur das verifizierte Ergebnis.

Funktionsweise:

• Identifizieren Sie das Refactoring namentlich. Schlagen Sie es im Katalog nach.
• Wenden Sie die benannte Übergangsmechanik auf einem entwicklerspezifischen Branch an. Validieren Sie sie anhand von produktionsnahen Daten.
• Öffnen Sie den PR. Die CI führt die Migration auf ihrem eigenen Branch aus und postet den Diff.
• Führen Sie den Merge durch, sobald der Diff und die Testergebnisse die Freigabe erhalten haben.

Anti-Pattern. Eine einmalige Schemaänderung, die sich keinem benannten Refactoring zuordnen lässt. Der Katalog mit über 70 Mustern deckt die gängigen Fälle ab. Wenn Sie sich außerhalb dieses Katalogs bewegen, kombinieren Sie wahrscheinlich mehrere Refactorings in einer einzigen Migration und sollten diese aufteilen.

Wie sich Jens Beispiel fortsetzt. Ihre V87-Migration ist das Split-Column-Refactoring: das Aufteilen von inventory_code in location_code, batch_number und serial_number. Die Katalogseite unter databaserefactoring.com/SplitColumns.html beschreibt die Übergangsmechanik. Ihr Branch war die Generalprobe; der CI-Lauf des PRs war die Verifizierung.

Praxisbeispiel #7: Entwickler können ihre Datenbanken nach Bedarf aktualisieren

Regel. Entwickler können den Datenbankstatus ihres Branches nach Bedarf aktualisieren: auf den aktuellen Status des Parent-Branches zurücksetzen, einen neuen Branch von der Produktion abspalten (forken), einen experimentellen Branch verwerfen oder einen Branch mit Teammitgliedern teilen. Alles in Sekundenschnelle.

Warum ist das jetzt eine dauerhafte Gewohnheit? „Nach Bedarf“ bedeutet im Jahr 2026: eine Sekunde, isoliert, mit produktionsnahen Daten. Keine dieser Operationen erfordert die Abstimmung mit Betriebskalendern oder DBA-Warteschlangen.

Funktionsweise:

• Zurücksetzen: Löschen und Neuerstellen des Branches aus seinem Parent-Branch.
• Von der Produktion abspalten (forken): databricks postgres create-branch --source production.
• Verwerfen: databricks postgres delete-branch.
• Teilen: Den Branch-Endpunkt an ein Teammitglied für eine Pairing-Session übergeben.

Anti-Pattern. Einen Branch über seinen eigentlichen Zweck hinaus als dauerhaft zu betrachten. Die Migration ist das dauerhafte Artefakt; der Branch ist der Arbeitsbereich.

Praxisbeispiel #8: Destruktives Testen als Standardoption

Regel. Wenn der Schadensradius einer destruktiven Aktion gleich null ist, wird destruktives Testen zu einer täglichen Option statt zu einer vierteljährlichen Übung.

Warum ist das jetzt eine dauerhafte Gewohnheit? Ein Branch lässt sich in einer Sekunde zurücksetzen. Alles, was Sie an einem Branch tun, kann rückgängig gemacht werden, indem Sie einen neuen Branch vom selben Parent-Branch erstellen. Destruktive Tests benötigen keine Betriebskalender und Freigabeprozesse mehr.

Dinge, die jetzt in einen normalen Feature-Zyklus passen:

• „Was passiert, wenn meine Migration auf halbem Weg durch die UPDATE-Anweisung fehlschlägt?“ Ausführen. Den Prozess bei 50 % abbrechen. Überprüfen, ob der Rollback funktioniert. Zurücksetzen.
• „Was passiert, wenn eine Backup-Wiederherstellung läuft, während ein Failover ausgelöst wird?“ Den unvollständigen Zustand simulieren. Das Verhalten der Anwendung überprüfen. Zurücksetzen.
• „Wie hoch ist die tatsächliche Wiederherstellungszeit (Time-to-Recover) für unser DR-Runbook?“ Runbook ausführen. Messen. Zurücksetzen.
• „Läuft diese Migration erfolgreich mit produktionsnahen Daten oder Datenmengen?“ vor dem C überprüfen

Kultureller Effekt. Wenn das Zurücksetzen nichts kostet, betrachten Teams die Testdatenbank nicht mehr als kostbare Ressource. Tests können aggressiver sein. Das Aufräumen kann übersprungen werden, da der nächste Branch wieder ganz neu startet.

Wie sich Jens Beispiel fortsetzt. Vor dem Erstellen ihres PRs nahm sie die produktionsnahen Daten auf ihrem Branch und korrumpierte absichtlich etwa ein Prozent der inventory_code-Werte, um Grenzfälle zu simulieren: fehlende Ziffern, eingebettete Leerzeichen, nachfolgende Leerzeichen. Typische Artefakte, die sich in historischen Daten ansammeln. Sie führte ihre Migration aus. Bei zwei Zeilen schlug ihre Substring-Berechnung fehl. Sie korrigierte das Skript und führte es erneut aus. Der Branch fing den destruktiven Test ab. Die Produktion hat davon nie etwas mitbekommen.

Praxisbeispiel #9: A/B-Prototyping auf Datenbankebene

Regel. Wenn zwei Designs zur Auswahl stehen, erstellen Sie diese auf parallelen Branches, vergleichen Sie sie mit produktionsnahen Daten und behalten Sie die bessere Lösung.

Warum ist das jetzt eine dauerhafte Gewohnheit? Die Kosten pro Branch liegen nahezu bei null. Das Erkunden von zwei Schema-Designs erfordert nicht mehr, sich im Voraus festzulegen, und es ist kein Bereitstellungsprozess (Provisioning) mehr nötig, den die meisten Teams für eine rein explorative Frage gar nicht erst starten würden.

Funktionsweise:

• Erstellen Sie zwei Branches vom selben Parent-Branch.
• Wenden Sie die Migration von Design A auf den einen Branch und die Migration von Design B auf den anderen an.
• Führen Sie die Anwendung für beide aus. Messen Sie die entscheidenden Faktoren: Abfragelatenz auf dem üblichen Lesepfad, Migrationszeit bei Produktionsvolumen, Index-Footprint, Lock-Contention unter simulierter Last.
• Wählen Sie die bessere Lösung. Verwerfen Sie die suboptimale Lösung. Dokumentieren Sie die Entscheidung in der PR-Beschreibung, damit die nächste Person, die das Schema erweitern muss, weiß, was in Betracht gezogen und warum dieses Design gewählt wurde.

Anti-Pattern. Das Ausführen von A/B-Prototypen, ohne die Entscheidung und die Begründung schriftlich festzuhalten. Die Branches sind in einer Sekunde weg; die Designentscheidung sollte von Dauer sein.

Wie sich Jens Beispiel fortsetzt. Sie zog zwei Designs für das Location/Batch/Serial-Feature in Betracht: drei neue Spalten in der bestehenden inventory-Tabelle oder eine separate inventory_attributes-Lookup-Tabelle mit dem Schlüssel inventory_id, in der Erwartung, dass später weitere Attribute hinzugefügt würden. Sie baute beide auf parallelen Branches von Staging auf. Sie führte den Lesepfad der Anwendung für beide aus, maß die Abfrageleistung mit produktionsnahen Daten und untersuchte, wie sich die jeweilige Migration bei Produktionsvolumen skalieren lässt. Die Lookup-Tabellen-Version schnitt auf dem üblichen Lesepfad schlechter ab, da jede Bestandsanzeige einen Join erforderte. Sie stellte die Spalten-Version bereit, verwarf den Branch mit der Lookup-Tabelle und hinterließ eine Notiz in der PR-Beschreibung: Lookup-Tabellen-Version in Betracht gezogen; abgelehnt, da der übliche Lesepfad zu einem Join wird. Neu bewerten, wenn mehr als fünf Attribute hinzukommen.

Was Jens neues Playbook zeigt

Wir haben die sieben Praktiken aus dem Jahr 2003 mit den Einschränkungen benannt, die fünf davon theoretisch bleiben ließen, sie für das Jahr 2026 nach der Einführung des Branchings neu formuliert und vier neue Praktiken hinzugefügt, die durch Branching ermöglicht werden. Insgesamt umfasst das neue Playbook für evolutionäre Datenbankentwicklung (Evolutionary Database Development) elf Praktiken, von denen 9 oben erklärt werden.

In Teil 1 – Jens Geschichte: ein Feature, eine Datenbank haben wir gesehen, wie Jen an einem Feature gearbeitet hat: Sie hat einen Code-Branch mit einem Lakebase-Branch verknüpft, in Sekundenschnelle eine echte Migration mit produktionsnahen Daten durchgeführt, ohne Mocks getestet, einen PR mit direkt eingefügtem Schema-Diff geöffnet und den Merge durchgeführt, wobei die Migration angewendet und die kurzlebigen Branches bereinigt wurden. Datenbankänderungen wurden Teil des normalen Entwicklungsprozesses.

In Teil 3 – Jens Team im großen Maßstab (At Scale) betrachten wir das Playbook bei fünfzig Entwicklern, die weiterentwickelten Aufgaben des DBAs in den Bereichen Richtlinienverwaltung und Governance sowie die Agents, die neben Jen Branches erstellen. Die Praktiken #10 und #11 werden dort ausführlich behandelt.

Der Leitfaden: Plugin-Walkthrough behandelt die Lakebase SCM-Erweiterung für VS Code und Cursor.

Ein Lakebase App Dev Kit für Agents, zusammen mit einem begleitenden E-Book für menschliche Anwender, wird im Anschluss veröffentlicht.

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