„Database Branching“ hat ein Branding-Problem.
Jahrelang meinte es meistens eines von drei Dingen:
Einen Dump/Restore-Marathon, der irgendwann zwischen dem nächsten Stand-up und dem Hitzetod des Universums endet.
Die Schema-pro-Branch-Illusion, bei der alle höflich so tun, als wäre „alles isoliert“, während Lock-Contention und Extension-Konflikte Wrestling spielen.
Ein „Clone“-Feature, das in Wahrheit nur bedeutet: „Wir haben Prod kopiert, bitte frag nicht nach der Rechnung.“
Also ja: Database Branching ist tot. Zumindest die Version, die Entwickler das Leben hassen lässt und Plattform-Teams Entwickler hassen lässt.
Aber die Idee selbst lebt mehr denn je. Sie wird nur gerade befördert. Der nächste Operator deiner Datenbank wird kein Mensch sein. Es wird ein Agent sein, der Incidents untersucht, Migrationen validiert, Schemaänderungen vorschlägt, Indizes optimiert, Performance-Experimente fährt und danach höflich fragt, ob er das alles in fünf Minuten noch einmal tun darf.
Die Zukunft sind Agents, CI, Preview-Umgebungen, QA-Automatisierung, Analytics-Sandboxes und schnelle Iteration, mit Datenbanken, die ständig und on demand entstehen, ohne dass man das Plattform-Team um Erlaubnis anbetteln muss.
Wenn deine Infrastruktur diesen Loop nicht unterstützt, hast du keine „agentic workflows“. Dann hast du nur einen schicken Chatbot, der Tickets erstellt. Und Tickets sind keine Control Plane.
Diese Welt braucht Branching. Sie braucht nur Branching, das keine Lüge ist.
Genau hier kommt Vela mit einer sehr klaren Botschaft ins Spiel: gleicher Postgres, andere Experience. Und entscheidend: anderes Branching.
Das Problem ist nicht PostgreSQL. Das Problem ist der Workflow darum herum.
PostgreSQL ist längst der Star dieser Geschichte. Battle-tested, tief erweiterbar, in Produktion bewährt und auf die bestmögliche Art langweilig.
Nicht langweilig ist dagegen, wie schmerzhaft normale Dinge rund um Postgres immer noch sind:
Du willst eine saubere Datenbank für ein Feature? Ticket.
Du willst realistische Daten für einen Test? Abstimmung, Freigaben und ein dreistufiges Ritual mit Dump-Datei und verlorener Würde.
Du willst eine Migration sicher testen? Viel Glück beim Verhandeln um eine geteilte Staging-Umgebung, die niemand anzufassen wagt.
Die Datenbank-Engine ist nicht das Problem. Die menschliche und inzwischen agentische Erfahrung darum herum ist der eigentliche Bug.
Versteh mich nicht falsch: Ich kenne Docker, ich nutze es selbst in Entwicklung und Unit-Tests. Aber es ist keine gute Erfahrung, ständig bei null anzufangen, Seed-Daten einzuspielen und zu hoffen, dass diese Seeds auch nur annähernd die echten Edge Cases aus Produktion enthalten.
„Branching“ bedeutet heute meist nur „Isolation vortäuschen“
Die meisten Lösungen für „Database Branching“ tappen in dieselbe Falle: Sie optimieren auf „sieht aus wie ein Branch“ statt auf „verhält sich wie ein Branch“.
Für mich ist der größte Täter der Schema-als-Branch-Ansatz. Er wirkt am Anfang verlockend, weil er billig ist und in eine einzelne PostgreSQL-Instanz passt. Aber er bringt eine verfluchte Liste von Nebenwirkungen mit:
Lock-Contention über Branch-Grenzen hinweg, weil es immer noch derselbe Server ist.
Extension-Konflikte, weil man eben nicht beliebig alles pro Branch unabhängig installieren oder konfigurieren kann.
Noisy-Neighbor-Probleme, weil sich alle dieselbe CPU-, RAM- und I/O-Budgets teilen. Isolation, die auf „bitte seid vorsichtig“ beruht, ist kein Sicherheitsmodell. Das ist ein Gebet.
Und am schlimmsten: Es ist kein echter Klon. Es ist nur eine „sichere“ Art, ein paar Schemaänderungen zu testen, bis du doch versehentlich gegen das falsche Schema ausführst. Rollen und Rechte können das etwas entschärfen. Viel Spaß beim Googeln nach „how do I restrict a user to a specific Postgres schema“.
Diese Art von Branching ist wie Raumteiler im Großraumbüro aufzustellen und das dann „privates Büro“ zu nennen. Klingt vertraut? Sei froh, wenn du überhaupt „Wände“ hast. Praktisch isst trotzdem jemand im nächsten Abteil Thunfisch.
Was Vela anders macht: Branches sind echte Datenbanken
Hier ist der Satz, der alles verändert:
In Vela sind Branches echte PostgreSQL-Datenbanken. Keine Schemata. Keine simulierten Namespaces. Keine „logischen Kopien“. Echte Postgres-Instanzen.
Jeder Branch läuft als vollständig isolierte Postgres-Instanz in seiner eigenen Micro Virtual Machine, mit Ressourcenlimits und Tenant-Grenzen, die nicht von gutem Benehmen abhängen.
Damit verschwindet sofort die ganze Klasse an Problemen, die klassisches Branching so fragil macht:
- Ein Branch kann andere Branches nicht aushungern.
- Ein Branch kollidiert nicht mit Extensions anderer Branches.
- Ein Branch teilt keinen Lock-Meltdown mit dem Nachbarn.
- Ein Branch „leckt“ kein Verhalten, weil er keinen Prozess teilt.
- Ein Branch kann nicht versehentlich Daten anderer Branches zerstören.
Für Nutzer ist das der Unterschied zwischen „nette Demo“ und „so testen und shippen wir unsere Software“.
Vela ist keine neue Datenbank. Genau das ist der Punkt.
Sagen wir es direkt: Vela ist nicht noch eine neue Datenbank-Engine.
Es erfindet keine neue Query-Sprache.
Es schiebt keine proprietäre Abstraktionsschicht zwischen dich und SQL.
Es ist kein Postgres-Fork mit einem Upgrade-Pfad, der in Tränen endet.
Vela nutzt Upstream-Postgres, also Vanilla-Source. Deine bestehenden Tools funktionieren weiter: ORMs, Migration-Tools, Treiber, BI-Tools, Skripte und auch dieses merkwürdige interne Tool aus 2017, das niemand anfassen darf.
Das ist wichtig. Denn in dem Moment, in dem deine „Branching-Plattform“ dich zwingt, alles neu zu platformisieren, ist es kein Branching mehr, sondern ein Berufswechsel.
Kontext ist König, für Menschen wie für Agents
Der alte Datenbank-Workflow geht davon aus, dass Menschen Reibung einfach hinnehmen.
- „Ticket erstellen.“
- „Warten.“
- „Abstimmen.“
- „Vorsichtig sein.“
- „Später aufräumen.“
Agents akzeptieren das nicht. CI akzeptiert das nicht. Schnelle Produktzyklen akzeptieren das nicht.
Die meisten Teams betreiben einen Zoo aus Produktion, Staging und Dev/QA. Das „funktioniert“, solange Refreshes selten sind und alle Drift tolerieren. Mit Agents knallt dieses Modell gegen eine Wand.
Wenn dein Workflow sichere, isolierte und realistische Datenbankumgebungen nicht schnell erzeugen kann, wird er zum Flaschenhals. Und der teuerste Teil ist nicht der Compute-Bedarf, sondern die verlorene Iterationsgeschwindigkeit.
Der Grund ist simpel: Staging driftet standardmäßig von Prod weg. Datenverteilungen divergieren. Extensions unterscheiden sich. Performance-Charakteristika verändern sich. Menschen flicken das mit Erfahrungswissen und Bauchgefühl. Agents haben kein Bauchgefühl. Sie haben Inputs.
Wenn ein Agent eine Migration auf veralteten oder unrealistischen Daten validiert, kann das Ergebnis logisch aussehen und trotzdem unter Produktionsverteilungen scheitern. Das ist kein LLM-Problem. Kein Menschenproblem. Es ist ein Kontextproblem. Und Kontextprobleme löst man nicht mit „besseren Prompts“.
Velas Modell dreht sich um Self-Service, echte Isolation, schnelles Branching und einfaches Wegwerfen. Damit werden Datenbank-Workflows etwas, das Teams im modernen Tempo wirklich betreiben können. Entwickler testen Migrationen ohne Shared Staging zu riskieren. QA validiert Features ohne Kalender-Schlachten. Analysten fahren schwere Queries, ohne Produktion an die lebenserhaltenden Maßnahmen zu hängen. Und Agents können ernsthafte Änderungen automatisch validieren und empfehlen.
Und Plattform-Teams bekommen endlich das, was sie wirklich wollen: Vorhersagbarkeit, klare Tenant-Grenzen und die Möglichkeit, „ja“ zu sagen, ohne für die Experimente aller anderen On-Call zu sein.
Der eigentliche Trick: Storage macht Branching billig
„Echte Datenbanken pro Branch“ klingt teuer, bis man versteht, dass Vela nicht naiv jedes Mal Terabytes kopiert.
Im agent-ready Blueprint in „Building an Agent-Ready Postgres Data Platform“ beschreibt Rob die Architektur, die genau zu diesem Workload passt: Shared-Everything plus Copy-on-Write (COW; in diesem Video erkläre ich die Vorteile und wie Copy-on-Write funktioniert).
Das mentale Modell ist einfach: Branches teilen sich einen Basis-Snapshot, Branch-Erstellung ist schnell, weil sie nur Metadaten anlegt, und der Storage-Overhead wächst nur mit dem, was sich pro Branch tatsächlich ändert, nicht mit der Größe von Produktion.
Vela nutzt simplyblock als verteilte Storage-Engine und ermöglicht dadurch Copy-on-Write-Semantik auf der Storage-Ebene.
Genau hier hört „database branching“ auf, ein Spezialereignis zu sein, und wird zu Infrastruktur, die man ganz selbstverständlich nutzt. Wie einen Git-Branch erstellen, nur eben mit einer Datenbank und entsprechend teureren Folgen, wenn man es falsch macht.
Das passt auch viel besser zur Realität von Agents. Der wertvollste Agent-Workload ist oft read-heavy: Schema analysieren, Verteilungen sampeln, Constraints validieren, EXPLAIN-Pläne ausführen, Migrationen testen. Dafür braucht man Produktionskontext. Idealerweise eine Produktionskopie. Aber eben keine vollständige physische Kopie aller Produktionsdaten. Genau dort zahlt sich COW aus.
Isolation ist notwendig, aber noch nicht genug
Agents brauchen zusätzlich Rechte- und Policy-Grenzen.
Der agent-ready Blueprint ist da klar: Du willst rollenbasierte Zugriffskontrolle, Quotas und Policies auf Umgebungsebene, die einschränken, wo ein Agent handeln darf und was er verändern darf.
Denn „ein Branch pro Aufgabe“ ist zwar eine Sicherheitsgrenze, aber die Plattform braucht trotzdem Governance. Branch-only Credentials, branch-scoped Permissions und ein sauberer Promote/Discard-Workflow sind keine optionalen Details. Sie entscheiden darüber, ob „Agents beschleunigen Arbeit“ oder „Agents beschleunigen Incidents“ gilt.
Weil Vela Isolation als erstklassiges Prinzip behandelt, sind die Branching-Primitiven um die Idee gebaut, dass du eine Umgebung gefahrlos wegwerfen können musst. Vela setzt Isolation mit Rechten, Ressourcenlimits und VM-Grenzen durch.
Also: Ist Database Branching tot?
Ja.
Die alte Version ist tot: Schema-Hacks, Dump/Restore-Rituale, der „Clone“-Button als heimlicher Kostenmultiplikator und der „vertrau mir, Bruder, das ist isoliert“-Ansatz.
Aber Database Branching als echter, sicherer und schneller Default-Workflow fängt gerade erst an.
Das Lustigste daran ist: Du brauchst nicht einmal vollständige MCP-(Model Context Protocol)-Verkabelung oder ein großes autonomes Runtime-System, um heute schon davon zu profitieren. Egal, ob du bereits agentisch arbeitest oder den Code noch selbst schreibst: Ein sofortiger Datenbank-Branch, geklont aus einem großen Datensatz, ist genau die Art, wie ich Änderungen, Fixes und Migrationen immer testen wollte. In großem Maßstab hatte ich dafür nie eine echte Chance. Bis jetzt.
Wenn du dir heute eine Branch-first-Gewohnheit aneignest, bei der jeder Migration-Check, jede Performance-Untersuchung und jedes riskante Experiment auf einem frischen Branch aus einer vertrauenswürdigen Basislinie läuft, legst du bereits das Fundament dafür, dass Agents später sicher arbeiten können. Du beweist, dass realistischer Kontext und strikte Isolation ohne Reibung zusammen existieren können.
Velas Wette ist einfach: Postgres bleibt langweilig, und die Experience hört auf, schmerzhaft zu sein.
Wenn du sehen willst, wie sich „branch-first“ Postgres anfühlt, probiere die Vela Sandbox aus und starte einen Branch, als würdest du es ernst meinen.