30. August 2026 · 6 Min. Lesezeit
LakeBase hat Postgres nicht neu erfunden. Es hat nur den fsync verschoben.
Databricks hat LakeBase Postgres ausgeliefert: echtes Postgres, drahtkompatibel, Standard-Treiber, ORMs, psql, pgvector und PostGIS inklusive. Auf AWS seit dem 22. Januar 2026 allgemein verfügbar, Azure GA im März, Adoption wächst Berichten zufolge doppelt so schnell wie die des Warehousing-Produkts. Es ist keine Neuimplementierung; die Query-Engine ist unverändertes Postgres. Was sich geändert hat, ist das unter dem Commit. Eine Transaktion wird nicht mehr dauerhaft, wenn eine lokale SSD leert. Sie wird dauerhaft, wenn ein Quorum von Speicherknoten zustimmt, dass sie passiert ist. Die Marketing-Schlagzeile ist Database Branching, „Git für Ihre Datenbank”. Die Schlagzeile ist der Nebeneffekt.
Was LakeBase ist
Die Produktdaten, kurz gehalten. Databricks hat Neon im Mai 2025 übernommen; LakeBase ist das Ergebnis. Serverless Postgres mit Scale-to-Zero, heute Postgres 18 mit pgvector, eine SLA seit Juli 2026, SOC 2 Type 2, PCI-DSS und HITRUST kamen diesen Monat, Speicherkontingent standardmäßig 32 TB, Lakehouse Sync schiebt operative Daten ohne Pipelines in Delta-Tabellen. PostGIS, Erweiterungen, die Tooling, die Sie ohnehin nutzen. Nichts davon ist der interessante Teil.
Der Mechanismus
Die Architektur zerlegt Postgres in zwei Schichten, verbunden durch einen WAL-Strom.
Compute ist zustandsloses Postgres. Es parst, plant, führt aus und hält nur transienten Zustand: Shared Buffers im RAM plus einen lokalen NVMe-Cache. Es besitzt keine dauerhaften Daten. Deshalb kann es neu starten, skalieren oder auf null skalieren, ohne eine Recovery-Story; es gibt nichts auf ihm wiederherzustellen.
Der WAL wird aus der Maschine in eine Gruppe von Safekeepers gezogen. Eine Transaktion committet, wenn ein Quorum den Datensatz per Paxos-Konsens bestätigt, nicht wenn ein lokaler fsync zurückkehrt. Das ist der Satz, aus dem alles andere folgt: der Commit ist ein verteiltes System-Ereignis.
Pageserver halten die Datendateien, wieder aufgebaut aus dem WAL. Sie materialisieren Seitenversionen bei Bedarf zu einem angeforderten LSN und arbeiten als Write-Through-Cache über dem Objektspeicher. Der Objektspeicher (S3 auf AWS) hält die unveränderliche Seitenhistorie und liegt abseits des heißen Lese-Pfads; nur Pageserver lesen daraus. Der Lese-Pfad ist Buffer Pool, lokales NVMe, Pageserver, Objektspeicher, gestoppt beim ersten Cache-Treffer.
Sie haben die fsync-Latenz einer lokalen SSD gegen die Konsens-Latenz eines replizierten Logs getauscht. Databricks argumentiert, das sei für jeden, der ohnehin synchrone Replikation betreibt, ein Waschen: eine Netzwerk-Roundtrip ersetzt eine andere, statt eine hinzuzufügen. Fair, aber beachten Sie, was sich geändert hat. Die Dauerhaftigkeit Ihres Commits hängt jetzt von der Gesundheit eines verteilten Quorums ab, und während einer Partition muss das System wählen zwischen blockierten Schreibzugriffen und einer möglichen Dauerhaftigkeitslücke. Ein Monolith musste diese Wahl nie treffen.
Warum Branching und Scale-to-Zero Folgen sind, keine Features
Hier ist der Teil, den es zu verinnerlichen lohnt. Vier Bulletpoints auf der LakeBase-Landingpage sind eine architektonische Entscheidung in vier Hüten.
Ein Branch ist eine Metadaten-Operation, die auf einen LSN zeigt. Es werden keine Daten kopiert. Eine 10-GB- und eine 2-TB-Datenbank branchen in derselben Anzahl Sekunden, und Sie zahlen nur für die Seiten, die der Branch verändert; ändern Sie 1 GB in einer 100-GB-Datenbank, kostet der Branch etwa 1 GB extra.
Scale-to-Zero ist derselbe Satz von der anderen Seite gelesen. Compute besitzt nichts Dauerhaftes, also kann es verdunsten. Point-in-Time-Recovery ist Compute, das sich mit einem vergangenen LSN verbindet, nicht Daten wiederherstellt. Ein Read Replica ist ein zweites Compute an vorhandenem Speicher, ohne Datenbewegung. Vier Features, eine Ursache.
Die Bilanz der Kompromisse
Externalisierte Dauerhaftigkeit ist ein Handel, und die Bilanz hat zwei Spalten.
| Eigenschaft | Monolithisches Postgres | LakeBase |
|---|---|---|
| Commit-Bestätigung | lokaler fsync | Quorum-Konsens übers Netzwerk |
| Kaltes Seitenlesen | Basisabbild auf der Festplatte | WAL-Deltas bis zum LSN nachspielen |
| Datenbank-Branch | pg_dump, Minuten bis Stunden | Metadaten-Operation, Sekunden |
| Idle-Compute | rund um die Uhr abgerechnet | 0 $ |
| Superuser, Tablespaces, logische Replikation | verfügbar | nicht verfügbar |
Die Zeile der kalten Seiten verdient Respekt. Die aktuelle Version einer Seite aufzulösen kann bedeuten, eine lange Kette von WAL-Deltas über einem Basisabbild nachzuspielen, und wenn Compaction und Image-Generierung falsch getunt sind, entsteht Tail-Latenz, die in keiner Demo auftaucht und um 3 Uhr nachts sehr wohl. Databricks’ eigenes Engineering bestätigt, dass das real war: Sie haben Full Page Writes deaktiviert und die Image-Generierung in den Pageserver verschoben und 94% weniger WAL-Traffic sowie bis zu 5× Schreibdurchsatz berichtet. Diese Engineering-Anstrengung unternimmt man nicht für ein Problem, das es nicht gibt.
Der Rest der Bilanz, aus Analysen Dritter. Branching hat keine Merge-Semantik: Ein Branch ist ein Snapshot an einem LSN und synchronisiert sich nie mit seinem Parent zurück, also bricht das Git-Mentalkonzept exakt dort, wo Git am nützlichsten ist, beim Merge. Langlebige Branches pinnen Seitenhistorie und treiben die Speicherkosten leise hoch; unveränderlicher Speicher ist billig zu schreiben und teuer zu vergessen. Verbindungen sind in einer Weise ephemeral, die Session-Zustand überrascht: ein 24-Stunden-Idle-Timeout, eine maximale Lebensdauer von 3 Tagen, ein Cold-Resume von etwa 500 ms, und Advisory Locks, Temp Tables und Prepared Statements sterben mit der Verbindung. Hochverfügbarkeitskonfigurationen können nicht auf null skalieren, Produktions-Compute rechnet also rund um die Uhr. Und Governance ist ausgerichtet, nicht verschmolzen: Unity Catalog regiert die Lakehouse-Abfrageflächen, Postgres-Rollen die direkten Verbindungen, zwei Autorisierungspfade, die konsistent zu halten sind.
Keines davon ist fatal. Alles davon ist der Preis.
Wo dies verallgemeinerbar ist
Der übertragbare Test: Wenn ein Datenbankanbieter Features auflistet, gruppieren Sie sie nach der architektonischen Entscheidung, die sie impliziert, und bepreisen Sie dann die Entscheidung, nicht die Liste.
LakeBases Liste, Branching, Scale-to-Zero, PITR, sofortige Replikas, Sync-Tabellen nach Delta, eine Speichergrundlage für OLTP und Analytics, folgt alles aus dem Satz „Dauerhaftigkeit lebt in einem verteilten Log über Objektspeicher”. Die Kosten, Konsens im Commit-Pfad, Verwaltung kalter Seiten-Tails, GC-Disziplin, Ephemeralität von Sessions, folgen aus demselben Satz. Sie können die Features nicht annehmen und die Kosten ablehnen; es ist dieselbe Entscheidung.
Das gilt für jedes Externalized-Durability-System, das Sie ab hier bewerten werden: Aurora’s getrennte Speicherschicht, Neon selbst, jede disaggredierte OLTP-Engine auf der Roadmap. Jedes stellt denselben Handel in einer anderen Verpackung auf den Tisch, und die Bewertung besteht immer aus denselben zwei Fragen. Welche Features sind Folgen der Speicherentscheidung? Was kostet die Speicherentscheidung um 3 Uhr nachts statt in der Demo?
Die Falle
Die Falle ist, die Feature-Liste als das Produkt zu lesen. Branching ist nicht das Produkt. Ein quorum-bestätigter WAL im Objektspeicher ist das Produkt, und Branching ist eine der Dinge, die diese Architektur kann und ein Monolith nicht.
Die zweite Falle ist die Lücke zwischen Demo und Produktion. Die vom Anbieter berichteten pgbench-Zahlen, etwa 1731 TPS für LakeBase gegen rund 1508 für Aurora PostgreSQL auf derselben 4M-Zeilen-Workload, sind Dauerzustands-Zahlen. Im Dauerzustand sehen disaggredierte Architekturen am besten aus; in den Tails lebt die Bilanz. Latenz beim Nachspielen kalter Seiten, Quorum-Verhalten unter Partition, GC-Druck durch einen vergessenen Branch: nichts davon erscheint in einer 90-Sekunden-Demo, alles davon erscheint in einer Seite.
Die Schlussregel. Wenn Dauerhaftigkeit zu einem verteilten System-Ereignis wird, sieht jede Folge dieser Entscheidung, auf beiden Seiten der Bilanz, wie ein Feature aus, bis Sie wissen, aus welchem Satz sie gefallen ist. LakeBases Satz lautet: „Der Commit lebt in einem Quorum über Objektspeicher.” Lesen Sie den Satz, und die Bulletpoints hören auf, Marketing zu sein, und werden Arithmetik.