Database Branching

Eine Datenbank ist der Ort, an dem eine App ihre Daten dauerhaft ablegt: Nutzerkonten, Bestellungen, Nachrichten. Wer an so einer App etwas ändert, will diese Daten nicht kaputt machen. Database Branching löst das Problem, indem es einen Zweig erzeugt: eine zweite, eigenständige Version der Datenbank, die im selben Moment denselben Inhalt hat wie das Original. In diesem Zweig kann man Daten löschen, Tabellen umbauen oder neue Funktionen testen, ohne dass das Original davon etwas merkt. Wenn der Test schiefgeht, wirft man den Zweig einfach weg. Wenn er gelingt, überträgt man die Änderung auf die echte Datenbank.

Warum Entwickler nicht mehr auf der echten Datenbank testen wollen

Früher gab es in vielen Teams genau eine Testdatenbank für alle. Wer sie gerade benutzte, blockierte die anderen. Und wenn jemand versehentlich alle Datensätze löschte, standen mehrere Leute still. Mit eigenen Zweigen bekommt jede Person und jede Aufgabe eine eigene Umgebung.

Der zweite Grund ist Realismus. Eine leere Testdatenbank verhält sich anders als eine mit Millionen Zeilen. Fehler, die erst bei großen Datenmengen auftreten, findet man dort nie. Ein Zweig enthält dagegen exakt die Struktur und den Umfang der echten Daten. So testet man unter realistischen Bedingungen, ohne das Original zu riskieren.

Wichtig ist der Unterschied zu einem Backup. Ein Backup ist eine Sicherheitskopie für den Notfall und wird selten angefasst. Ein Zweig ist ein Arbeitsplatz auf Zeit, den man absichtlich benutzt und danach wegwirft. Beide sind Kopien, aber sie haben völlig verschiedene Zwecke.

Der Trick mit dem geteilten Speicher

Eine echte Kopie von 500 Gigabyte Daten würde lange dauern und viel Platz kosten. Deshalb kopiert Database Branching zunächst gar nichts. Der neue Zweig bekommt nur einen Verweis auf die bestehenden Daten. Er liest dieselben Speicherblöcke wie das Original.

Erst wenn im Zweig etwas geändert wird, entsteht eine echte Kopie – und zwar nur von dem winzigen Teil, der sich ändert. Dieses Prinzip heißt Copy-on-Write, also Kopieren erst beim Schreiben. Man kann es sich wie ein gemeinsam genutztes Skript vorstellen: Alle lesen dasselbe Original, und nur wer eine Seite bearbeiten will, zieht sich von genau dieser einen Seite eine eigene Fassung.

Deshalb ist ein Zweig meist in ein bis zwei Sekunden fertig und belegt am Anfang fast keinen Speicher. Er wächst nur in dem Maß, in dem man ihn verändert. Ein typischer Testzweig bleibt so oft unter einem Prozent der Größe des Originals. Das Vorbild ist die Software Git, mit der Programmierer ihren Programmcode in Zweigen verwalten – Database Branching überträgt diese Idee auf die Daten.

Von der Cloud-Datenbank bis zum Pull Request

Anbieter moderner Cloud-Datenbanken wie Neon, PlanetScale oder Supabase werben ausdrücklich mit dieser Funktion. Man klickt auf einen Knopf oder tippt einen Befehl, und der Zweig existiert. Klassische Datenbanken auf eigenen Servern können das meist nicht ohne Zusatzsoftware. Das ist einer der Gründe, warum viele Teams überhaupt in die Cloud wechseln.

Im Arbeitsalltag läuft es oft automatisch ab. Schlägt ein Entwickler eine Änderung am Programmcode vor, erzeugt das System dazu automatisch einen passenden Datenbankzweig. Dort laufen die automatischen Tests. Wird der Vorschlag angenommen oder verworfen, löscht sich der Zweig von selbst wieder.

Auch bei KI-Werkzeugen taucht der Begriff zunehmend auf. Wenn ein Programmierassistent selbstständig Änderungen an einer Datenbank ausprobieren soll, gibt man ihm einen Zweig statt der echten Daten. Richtet er dort Schaden an, kostet das nichts. Ein häufiger Irrtum ist übrigens, ein Zweig sei automatisch datenschutzkonform. Er enthält dieselben echten Kundendaten wie das Original – wer sie nicht braucht, muss sie vorher unkenntlich machen.