Warum Postgres mit getrenntem Storage und Compute die richtige Datenbank für KI-Agenten ist
Jahrzehntelang wurde eine Datenbank von einem Menschen provisioniert: Du hast eine Instanz dimensioniert, gewartet, dafür bezahlt — egal ob sie ausgelastet war oder nicht — und das selten und sorgfältig getan. KI-Agenten kehren jeden Teil davon um — vor allem die Sorgfalt.
Ein Agent, der eine App baut, will seine Datenbank so, wie er eine Datei will: an Ort und Stelle erstellt, im selben Atemzug iteriert, weggeworfen, wenn sie falsch ist. Und das alles muss er ohne Sorgfalt tun können — ohne einen Menschen, der abwägt, ob eine Migration sicher ist, ob ein Backfill umkehrbar ist, ob das Hochfahren noch einer Datenbank den Aufwand wert ist. Der ganze Wert eines Agenten liegt darin, dass er handelt; eine Datenbank, um die er herumschleichen muss, bringt den Loop ins Stocken.
Die eigentliche Frage lautet also nicht „Wie geben wir einem Agenten eine Datenbank?". Sie lautet: Wie machen wir Datenbankoperationen billig und umkehrbar genug, dass ein Agent sie frei erstellen, on the fly iterieren und seine Fehler selbst korrigieren kann? Das ist eine Architekturfrage, und die Antwort ist, die Daten nicht länger an einen laufenden Prozess zu koppeln.
Das ist nicht spekulativ. Als Databricks 2025 Neon übernahm, war die Schlagzeile, dass über 80 % der Datenbanken auf der Plattform von KI-Agenten erstellt wurden, nicht von Menschen — gegenüber ~30 % ein Jahr zuvor, wobei Agenten Tausende Datenbanken pro Tag anlegten. Das Provisioning-Modell, das für langlebige Instanzen im menschlichen Tempo gebaut wurde, ist für diese Last das falsche Werkzeug.
Dieser Beitrag ist das architektonische Argument: wie agentische Datenbanklast tatsächlich aussieht, warum die naheliegenden Entwürfe scheitern und wie drei Primitive — Copy-on-Write-Branching in O(1), Scale-to-Zero-Compute und Branch-at-LSN — sauber auf das abgebildet werden, was Agenten tun. Die Begleitbeiträge behandeln zwei dieser Mechanismen im Detail (Scale-to-Zero, Time-Travel); dieser hier erklärt, warum es die richtigen Primitive sind.
Die Form agentischer Datenbanklast
Die Beziehung eines Agenten zu einer Datenbank hat fünf Eigenschaften, die die eines Menschen nicht hat:
- Zahlreich. Ein einziger Agenten-Lauf kann mehrere Datenbanken brauchen (pro App, pro Experiment, pro Test). Über eine Plattform hinweg sind das Tausende, von Software in Maschinengeschwindigkeit erstellt.
- Sofort. Der Agent behandelt eine Datenbank wie eine Datei — er erwartet, eine zu erstellen und sie im selben Atemzug zu nutzen, nicht ein Ticket einzureichen und Minuten zu warten.
- Meist im Leerlauf. Die allermeisten sind Experimente, halbfertige Builds oder Apps, die auf ihren ersten Nutzer warten. Die aggregierte Auslastung ist niedrig; der Long Tail ist riesig.
- Isolation erforderlich. Der Fehler eines Agenten in der Datenbank einer App darf die einer anderen nicht berühren. Mandantentrennung per Filter reicht nicht, wenn der Mandant ein unbeaufsichtigtes Programm ist.
- Fehleranfällig und irreversibel. Agenten führen Migrationen und
UPDATEs selbstbewusst und gelegentlich katastrophal aus. Die Daten brauchen ein Undo.
Das Bild, das du im Kopf behalten solltest: ein Fan-out aus vielen Datenbanken, fast alle davon grau.
Warum die naheliegenden Entwürfe scheitern
Eine Instanz pro App. Korrekte Isolation, aber das Provisioning ist langsam (Sekunden bis Minuten), und jede Instanz trägt einen permanenten Kostensockel — RAM, einen Prozess, Storage — egal ob jemand verbunden ist oder nicht. Multipliziere das mit dem Leerlauf-Long-Tail, und die Rechnung wird von Datenbanken dominiert, die niemand nutzt. In Agentengröße ein Nonstarter.
Eine große geteilte Datenbank, per Schema/RLS isoliert. Billig und schnell, aber sie gibt genau die Isolation auf, die du am dringendsten brauchst: Eine schlechte Migration oder ein außer Kontrolle geratener Query im Schema einer App ist jetzt ein Ereignis mit geteiltem Blast Radius, und „die Daten dieser App rückgängig machen" bedeutet, sie chirurgisch aus denen aller anderen herauszulösen. Akzeptabel, wenn ein Mensch im Loop ist; nicht, wenn der Akteur ein autonomer Agent ist.
Der Konflikt ist real: Du willst Isolation auf Instanzniveau zu Kosten und Geschwindigkeit auf Dateiniveau. Das ist nur möglich, wenn du die Daten der Datenbank nicht länger an einen laufenden Prozess koppelst.
Die drei Primitive, die passen
Trenne Storage von Compute — die Daten liegen in einem versionierten Page Store, der Postgres-Prozess ist zustandslos und liest Pages bei Bedarf — und drei Primitive fallen heraus, jedes beantwortet eine Eigenschaft der Last:
| Eigenschaft der Last | Primitiv | Warum es passt |
|---|---|---|
| Sofort, zahlreich | Copy-on-Write-Branch in O(1) | Eine neue Datenbank ist ein Metadaten-Pointer, keine Kopie — im Sub-Sekunden-Bereich, unabhängig von der Größe. Der Agent erstellt sie wie eine Datei. |
| Meist im Leerlauf | Scale-to-Zero-Compute | Entferne den Prozess, wenn niemand verbunden ist; die Daten bleiben im Page Store. Inaktive Datenbanken kosten ~nichts. |
| Isolation, Undo, Experimentieren | Branch an einem LSN | Forke den exakten Zustand zu einem Zeitpunkt, Copy-on-Write. Billige isolierte Kopien, sofortiger Rollback, parallele Versuche. |
1. Copy-on-Write-Branch → sofort, zahlreich
Eine Datenbank zu erstellen heißt, eine Timeline zu branchen: Der Child teilt sich die unveränderten Pages des Parent und schreibt eine Page erst dann, wenn er divergiert. Es wird kein Byte kopiert, daher ist das Erstellen O(1) in Metadaten — gleich, ob der Parent ein Kilobyte oder hundert Gigabyte hält. Ein Agent kann in der Zeit, die er zum Schreiben einer Datei braucht, ein vollständig isoliertes Postgres provisionieren, und das tausendmal tun, ohne dass die Storage-Rechnung mit der Anzahl skaliert.
2. Scale-to-Zero → meist im Leerlauf ist gratis
Weil die Daten nicht an den Prozess gebunden sind, kannst du den Prozess löschen. Wenn niemand verbunden ist, skaliert das Compute auf null; die nächste Verbindung weckt es transparent. Der Leerlauf-Long-Tail — der Großteil der Flotte — kostet nur Storage, keine laufenden Instanzen. Die Kosten werden proportional zu tatsächlich bedienten Queries, nicht zu provisionierten Datenbanken. (Wie das Aufwecken unsichtbar gemacht wird — Wire-Protocol-Parsing, Single-Flight-Wake, Connection-Parking — steht im Scale-to-Zero-Beitrag.)
3. Branch an einem LSN → Isolation, Undo, Experimentieren
Dasselbe Branch-Primitiv, an eine bestimmte WAL-Position gepinnt, ist das für Agenten relevanteste. Es gibt dir:
- Umkehrbarkeit. Tagge pro Generierung einen Checkpoint; das Wiederherstellen forkt den Zustand an diesem LSN und richtet die App darauf aus — Code und Daten rollen gemeinsam zurück. Die selbstbewusst-aber-falsche Migration eines Agenten wird zu einem Undo per Klick. (Der Time-Travel-Beitrag ist der Deep Dive.)
- Sicheres Experimentieren. Ein Agent kann die Datenbank forken, eine zerstörerische Migration oder einen Daten-Backfill ausprobieren, sie verifizieren und den Branch behalten oder verwerfen — ohne die echten Daten anzufassen.
- Parallele Versuche. Forke pro Ansatz einmal vom selben Seed und lasse sie nebeneinander laufen; CoW bedeutet, dass N Branches nicht N Kopien kosten.
Der Gewinn: ein Agent, der nicht vorsichtig sein muss
Einzeln sind das ein Kostenvorteil und ein paar Features. Zusammen verändern sie, was ein Agent tun darf.
Mach das Erstellen O(1) und den Leerlauf gratis — und der Agent hört auf, Datenbanken zu rationieren: Er fährt eine pro App, pro Experiment, pro Preview hoch, mitten in der Aufgabe, ohne dass eine Kosten- oder Latenzrechnung im Weg steht. Mach jeden Zustand umkehrbar mit einem Branch-at-LSN — und der Agent hört auf, bei Mutationen konservativ zu sein: Er kann die Migration ausführen, bei der er sich unsicher ist, eine Tabelle backfillen, das zerstörerische Refactoring versuchen, weil der Preis des Irrens ein verworfener Branch oder ein Rollback per Klick ist, kein Datenverlust-Vorfall.
Genau das ist der Durchbruch. Ein Agent, der bei der Datenbank vorsichtig sein muss, ist ein Agent, der entweder ins Stocken gerät (anhält, um einen Menschen zu fragen „ist das sicher?") oder etwas kaputt macht, das er nicht rückgängig machen kann. Ein Agent auf billigem, sofortigem, umkehrbarem Storage kann das tun, worin Agenten wirklich gut sind — handeln, beobachten, korrigieren — mit Daten genau so, wie er es bereits mit Code tut: on the fly erstellen, an Ort und Stelle iterieren, forken, um einen zweiten Ansatz zu probieren, den zurückrollen, der nicht funktioniert hat. Kein Herumschleichen.
Das ist auch, was die Übergabe des Datenbank-Lebenszyklus an einen Agenten überhaupt erst sicher macht. Die Garantie ist nicht „der Agent ist vorsichtig" — sie ist „die Fehler des Agenten sind billig rückgängig zu machen". Das sind sehr unterschiedliche Wetten, und nur die zweite skaliert zur Autonomie.
Wie Adorable das komponiert
Die Primitive sind die von Neon; die Komposition für einen mandantenfähigen App-Builder ist unsere:
- Ein geteilter Neon-Tenant trägt die gesamte Plattform — ein einziger Page Store und WAL-Service. Branching ist genau deshalb billig, weil sich alles den Storage teilt.
- Eine Timeline pro Projekt ist die Datenbank dieses Projekts; Schemas und Rollen pro App isolieren Apps, die sich den Branch eines Projekts teilen.
- Ein Connection-Proxy routet nach Datenbankname (
proj_{id}), skaliert das Compute-Deploymentjedes Projekts 0↔1 und parkt Verbindungen über ein Aufwecken hinweg — die Scale-to-Zero-Maschinerie. - Checkpoints + Branch-at-LSN geben jedem Projekt point-in-time Time-Travel für Code und Daten, festgehalten an denselben git-Commits, die der Agent produziert.
Isolation lebt auf der Ebene von Timeline + Rolle + Kubernetes-Namespace, nicht auf der des Tenants — und genau das lässt Tausende Projektdatenbanken sich ein Storage-Backend billig teilen, während sie voneinander abgeschottet bleiben.
Das Kostenmodell ist die Pointe
Folge dem Geld. Mit Instanz-pro-App gilt Kosten ≈ Anzahl provisionierter Datenbanken, für immer. Mit getrenntem Storage + Scale-to-Zero gilt Kosten ≈ tatsächlich bediente Queries plus eine dünne Storage-Linie — und Copy-on-Write hält den Storage sublinear in der Anzahl der Branches. Für eine Flotte, die überwiegend im Leerlauf und fast vollständig von Agenten erstellt ist, sind das keine kleinen Konstantfaktor-Unterschiede; es sind verschiedene Asymptoten. Es ist das einzige Modell, in dem „gib jeder App und jedem Experiment seine eigene echte Datenbank" wirtschaftlich vernünftig ist.
Das ist die ganze Wette, und deshalb konvergiert die Branche hier: Die Datenbank für KI-Agenten ist keine kleinere oder schnellere Instanz — sie ist eine, in der die Daten vom Prozess entkoppelt sind, sodass das Erstellen sofort, der Leerlauf gratis und jeder Punkt der Historie einen Branch entfernt ist. Was dasselbe ist, dreifach gesagt: Der Agent darf die Datenbank wie Code behandeln — sie on the fly erstellen, an Ort und Stelle iterieren und ohne Angst rückgängig machen.