Supabase Branching ist kein Backup. Es geht nur vorwärts.

Du hast Supabase Branching angeschaltet, weil es nach der sorgfältigen Art zu arbeiten aussah. Neben deinem Projekt steht jetzt ein Preview-Branch, Änderungen werden dort ausprobiert, bevor sie jemand sieht, und das Ganze fühlt sich deutlich sicherer an als noch letzten Monat.

Es ist auch sicherer. Es ist nur kein Backup, und der Unterschied zeigt sich an genau einem Tag.

Hier ist der Punkt, den die Branching-Anleitungen überspringen: Ein Branch ist eine zweite Datenbank neben deiner ersten, keine frühere Fassung davon. Branching ist der Ort, an den du gehst, bevor du etwas änderst. Ein Backup ist der Ort, an den du gehst, wenn schon etwas schiefging. Branching anzuschalten legt nirgendwo eine Kopie deiner Daten ab.

Ist Supabase Branching ein Backup?

Nein. Ein Branch startet als leere Datenbank im Gewand deines Schemas, und nichts am Branching legt einen älteren Stand deiner Daten zurück.

Supabases eigene Dokumentation ist da deutlich: „Neue Branches starten ohne jegliche Daten aus deinem Hauptprojekt. Das soll deine sensiblen Produktionsdaten besser schützen." Ein Branch wird aus deinen Migrationen gebaut, und eine Migration beschreibt die Form einer Datenbank. Die Tabellen, die Spalten, die Policies. Nie die Zeilen.

Der Branch neben deinem Projekt ist also nicht die Kopie von Dienstag. Er ist eine neue Datenbank, die deine Nutzer nie gesehen hat.

Wenn du nie festgestellt hast, was deine Datenbank eigentlich kopiert, ist genau das die Aufgabe, zu der dieser Artikel dich schicken will, und dein Tarif klärt das meiste davon in zwei Minuten.

Was ein Branch tatsächlich ist

Ein ganzes zweites Supabase-Projekt, mit allem Eigenen.

„Jeder Branch ist eine eigene Umgebung mit eigener Supabase-Instanz und eigenen API-Zugangsdaten", schreibt die Dokumentation. Eigener Connection String, eigene Keys, eigenes Storage, eigene Login-Konten, eigene Zeilen. Nichts darin ist mit dem Projekt verdrahtet, auf dem deine Nutzer sitzen, und genau das macht es sicher, darin etwas kaputtzumachen.

Diese Abschottung ist die ganze Funktion, und sie ist auch der Grund, warum er nicht nebenbei ein Backup sein kann. Die Kopie deiner Daten, auf die du gehofft hast, wurde nie gezogen, und der Ort, an dem du sie suchen würdest, ist seit dem Tag seiner Entstehung leer.

Was ein Merge tut, und was er nicht tut

Er trägt deine Schema-Änderungen in die Produktion. Er trägt nie Zeilen, in keine Richtung, zu keinem Zeitpunkt.

Beim Mergen spielt Supabase die Migrationen deines Branches gegen deine Produktionsdatenbank und liefert deine Edge-Function-Änderungen aus. Das ist die ganze Fracht. Eine neue Tabelle, eine neue Spalte, eine umgeschriebene Policy: Die reisen mit. Die Zeilen, die du beim Testen angelegt hast, bleiben im Branch, und die Zeilen in der Produktion bleiben genau so, wie sie waren, einschließlich derer, die du ersetzen wolltest.

Leute erwarten eine Fassung davon, die es nicht gibt: einen Merge, der in die Produktion greift und die Dinge zurücklegt. Was Branching stattdessen hat, ist ein Deployment, nach vorne gespielt, auf das, was zu dem Zeitpunkt gerade in der Produktion steht.

Aber ich habe meine Produktionsdaten in den Branch geklont

Dann hast du eine Kopie deiner Zeilen, und drei Dinge an dieser Kopie entscheiden, was sie an dem Tag wert ist, an dem du sie brauchst.

Das geht, und es ist nichts Exotisches. Die Supabase-CLI beschreibt den Schalter als „ob Produktionsdaten in die Branch-Datenbank geklont werden sollen", und die Management-API nimmt dieselbe Option beim Anlegen eines Branches. Hast du sie benutzt, hält dein Branch tatsächlich deine Daten.

• Sie wurde einmal gezogen. Der Klon passiert beim Anlegen des Branches, und danach füllt ihn nichts nach. Jede Bestellung, jede Anmeldung und jeder Kommentar seitdem liegt in der Produktion und sonst nirgends, und das ist der ganze Unterschied zwischen einer Kopie und einem Zeitplan.
• Sie liegt im selben Konto. Ein Branch ist ein weiteres Projekt unter derselben Organisation, auf derselben Karte, hinter demselben Login. Jeder Weg, dein Supabase-Konto zu verlieren, nimmt den Branch mit, und das ist ein anderes Unglück als das Kaputtmachen der eigenen Daten.
• Niemand hat sie zurückgelesen. Ein Klon, der halb durchlief, sieht von außen genauso aus wie einer, der fertig wurde, bis zu dem Moment, in dem du ihn öffnest.

Der Branch ist der Teil, der verschwinden soll

Ein Preview-Branch wird gelöscht, sobald sein Pull Request gemergt oder geschlossen wird. Das ist das dokumentierte Verhalten der Funktion.

Supabase nennt Preview-Branches „kurzlebig und am besten geeignet für gezieltes Testen" und sagt, sie „werden automatisch gelöscht, wenn ein PR gemergt oder geschlossen wird". Die andere Sorte, persistente Branches, sind „langlebig und empfohlen für Umgebungen wie Staging, QA oder Entwicklung", und die überstehen das Schließen des Pull Requests.

In der Standardeinstellung ist der Branch mit deiner einzigen geklonten Kopie also genau das, was dein Arbeitsablauf an dem Tag wegwirft, an dem die Arbeit fertig ist. Ihn zu behalten heißt, ihn persistent zu machen, und ein persistenter Branch ist ein zweites laufendes Supabase-Projekt. Supabase führt Branching auf den bezahlten Tarifen und rechnet es pro Branch und Stunde ab, nachzulesen auf ihrer Preisseite.

Wofür Branching wirklich gut ist

Für eine ganze Menge, und dieser Artikel wäre unehrlich, wenn er das nicht sagte.

Ein Branch ist der billigste Ort, um herauszufinden, dass eine Migration eine Spalte entfernt, bevor sie die Spalte entfernt, in der deine Kunden sitzen. Du kannst eine Policy-Änderung an einer Datenbank proben, die genau wie deine geformt ist, mit eigenen Keys, sodass ein Fehler niemanden erreicht. Er gibt einer KI einen Ort, an dem sie falsch liegen darf und der nicht deine Live-App ist. Ein Backup kann nichts davon.

Die Lücke liegt darin, welche Art Unglück er abdeckt. Branching schützt die Änderungen, die durch einen Pull Request laufen. Das meiste, was Leuten tatsächlich ihre Daten kostet, kommt dort nie vorbei: ein Löschen im Supabase-Tabelleneditor, das mehr Zeilen traf als gemeint, ein Seed-Skript, das auf das Live-Projekt zeigte, eine Migration, die eine KI schrieb und du um ein Uhr nachts abgenickt hast, ein Aufräumen von scheinbaren Testdaten. Nichts davon läuft auf dem Weg in die Produktion durch einen Branch, und das ist derselbe Grund, aus dem ein Rücksprung im Code keine gelöschte Tabelle mitbringt.

Diese zweite Art Unglück ist das, was ein Backup beantwortet. Es steht hinter dir in der Zeit und hält den Stand deiner Datenbank zu einem Moment, den du benennen kannst, damit ein Fehler außerhalb deines Arbeitsablaufs noch irgendwohin zurückkann.

Genau das ist auch Reeve Care: geplante Kopien deiner Supabase-Datenbank, außerhalb deines Supabase-Kontos aufbewahrt, zurückgelesen und geprüft, bevor eine davon als gemacht zählt. Verbinde deine Storage-Buckets, und die von deinen Nutzern hochgeladenen Dateien fahren mit, sodass eine Wiederherstellung die Zeilen zurücklegt und die Bilder, auf die sie zeigen.

Lass Branching so oder so an. Nichts oben ist ein Argument, es abzuschalten.

Was du diese Woche tun solltest

Bevor du diesen Tab schließt: Öffne dein Supabase-Projekt und sieh nach, ob irgendetwas nach Zeitplan eine Kopie zieht. Diese eine Antwort ist die ganze Arbeit von heute, und Branching ändert daran nichts. Die 10-Minuten-Sicherheitscheckliste deckt sie zusammen mit dem Übrigen ab, was bei einer frisch gestarteten App zu bestätigen ist, und was eine Kopie enthält und was der Knopf tatsächlich tut, steht auf der Seite zu Supabase-Backups.