Databricks Lakebase: Wann Managed Postgres im Lakehouse sinnvoll ist
Die Kernaussagen auf einen Blick.
- Databricks Lakebase ist eine verwaltete, Postgres-kompatible OLTP-Datenbank für Anwendungen, App-State, Agent-Memory und kleine transaktionale Workloads direkt im Databricks-Lakehouse.
- Lakebase eignet sich vor allem für neue Databricks Apps, KI-Agenten, Online-Lookups und Workflow-Statusdaten. Bestehende produktive Postgres-Datenbanken ersetzt sie nicht automatisch.
- Vor dem Einsatz sollten drei Fragen geklärt werden: Welche Workloads wirklich zu Lakebase passen, wie Daten zwischen Lakebase, Delta und Unity Catalog synchronisiert und geschützt werden und ob Funktionen, Region und Postgres-Erweiterungen im eigenen Setup verfügbar sind.
- Mein Vorschlag: Lakebase bei neuen Databricks Apps und Agents grundsätzlich prüfen, bestehende RDS-, Azure-Postgres- oder Cloud-SQL-Datenbanken aber dort belassen, wo Lastprofil, Extensions, Compliance oder Betriebsanforderungen dafür sprechen.
Inhaltsverzeichnis
Lakebase ersetzt nicht euer OLTP-System
Im Plattform-Review steht die Architektur-Folie an der Wand. Oben sitzt das Lakehouse mit Unity Catalog, daneben die Databricks-App fürs interne Forecast-Tool. Daneben läuft eine eigene Postgres-Datenbank, in der die Anwendung Einstellungen, Sitzungen und Bearbeitungsstände speichert. Im Review stellt sich die Frage, wo die Zugriffsrechte für diese Daten eigentlich verwaltet werden. Ein Teil der Rechte liegt in Unity Catalog, der andere direkt in Postgres. Im Audit wird dadurch sichtbar, dass zwei getrennte Berechtigungsmodelle betrieben werden.
Sobald Databricks Apps oder KI-Agenten produktiv eingesetzt werden, entsteht häufig dieselbe Architektur. Analysedaten liegen in Delta, während Anwendungsdaten in einer separaten Postgres-Datenbank gespeichert werden. Der Abgleich zwischen beiden Systemen benötigt einen eigenen Prozess und eine klare Verantwortung. Mit der Zeit unterscheiden sich Berechtigungen und Verantwortlichkeiten in beiden Systemen, der Datenfluss lässt sich an der externen Datenbank nicht mehr durchgängig nachvollziehen, und der KI-Agent speichert Daten außerhalb der zentralen Audit- und Governance-Sicht.
Wie lassen sich Analyse- und Anwendungsdaten unter einem gemeinsamen Betriebsmodell verwalten? Wer verantwortet Zugriff, Audit und Wiederherstellung der Daten, die ein Agent dauerhaft speichert? Und ab wann lohnt es sich, die externe Postgres dafür durch eine plattformnahe Schicht abzulösen?
Genau hier setzt Lakebase an. Lakebase ist eine gezielt für transaktionale Anwendungsdaten entwickelte Datenbankschicht. Wer Lakebase als vollständigen Ersatz für bestehende Datenbanken versteht, setzt die Technologie schnell für Workloads ein, für die sie nicht gedacht ist.
Was ist Databricks Lakebase?
Lakebase ist eine vollständig von Databricks verwaltete Postgres-Datenbank für Anwendungen und transaktionale Prozesse (Viele kleine Lese- und Schreibvorgänge, wie sie bei Anwendungen üblich sind) und Für Einstellungen, Sitzungen, Statusinformationen und das Gedächtnis von KI-Agenten. Databricks beschreibt sie als voll verwaltete Postgres-Datenbank, die in die Databricks-Plattform integriert ist und auf der Open-Source-Postgres-Engine läuft. Speicherung und Rechenleistung lassen sich unabhängig voneinander skalieren, Databricks stellt und skaliert die benötigte Rechenleistung automatisch, und die Daten können in die zentrale Governance von Unity Catalog eingebunden werden.
Lakebase verbindet drei Funktionen: Eine Datenbank, die sich weitgehend wie Postgres verwenden lässt, einen Speicher für Anwendungsdaten und Agenten-Gedächtnis und eine integrierte Plattformkomponente mit zentraler Berechtigungs- und Auditsteuerung. Sie ist gleichzeitig drei Dinge nicht. Für große Analysen und Reports bleiben Delta-Tabellen und SQL Warehouses zuständig. Sie ersetzt nicht jede bestehende Postgres-Datenbank mit ihren Erweiterungen und speziellen Betriebsanforderungen. Lakebase greift nicht nur auf eine externe Datenbank zu, sondern stellt selbst eine Datenbank bereit.
Die Konsequenz für die Architektur ist klar. Eine separate Datenbank für jede neue App erzeugt zusätzliche Aufgaben für Zugriffe, Backups, Monitoring und Betrieb. Eine pauschale Einführung kann dagegen dazu führen, dass kritische Bestandsdatenbanken zu früh migriert werden. Beides ist vermeidbar, sobald die Schicht klar als das gelesen wird, was sie ist: Eine Datenbank für neue transaktionale Workloads, die direkt innerhalb der Databricks-Plattform entstehen.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Autoscaling, Branching, Scale-to-Zero und Point-in-Time-Restore
Vier Funktionen prägen das Betriebsbild von Lakebase und unterscheiden die Schicht von einer klassischen Postgres-Instanz auf RDS, Azure Database for PostgreSQL oder Cloud SQL. Seit dem 12. März 2026 entstehen neue Lakebase-Instanzen standardmäßig als Autoscaling-Projekte; der bisherige Provisioned-Modus bleibt für Bestands-Instanzen sichtbar, läuft aber im Hintergrund auf Autoscaling zu.
Autoscaling. Compute wird in Compute Units (CU) gemessen, eine CU entspricht 2 GB Arbeitsspeicher. Lakebase passt die CU-Zahl in einem konfigurierten Min/Max-Korridor automatisch an CPU-Last, Memory-Verbrauch und Working-Set-Size an; der Spread liegt aktuell bei bis zu 8 CU im Autoscaling-Profil und maximal 32 CU in der Spitze. Skaliert wird ohne Restart und ohne Verbindungsabbruch. Damit entfällt das Sizing klassischer RDS-Instanzen, in dem die Instance-Klasse vorab gewählt und nachträglich nur mit Downtime verändert wird.
Scale-to-Zero. Nach einer konfigurierbaren Idle-Zeit suspendiert Lakebase die Compute-Ressourcen vollständig; bei der nächsten Verbindung läuft die Datenbank wieder an. Für unregelmäßig genutzte Apps, Dev-Branches und interne Dashboards nennt Databricks im Autoscaling-Blog Einsparungen ab 70 Prozent gegenüber dauerhaft laufenden Instanzen. In High-Availability-Konfigurationen ist Scale-to-Zero nicht verfügbar.
Branching mit Copy-on-Write. Ein Lakebase-Branch enthält Schema und Daten der Ursprungsdatenbank, teilt aber den Storage über Zeiger; geschrieben wird nur, was sich tatsächlich ändert. Damit lassen sich Dev-, Test- und PR-Umgebungen ohne vollständige Datenkopie aus dem Produktivstand erzeugen, jede mit eigenem Autoscaling-Compute. Das löst typische Probleme paralleler RDS-Stages: Drift zwischen Umgebungen, lange Snapshot- und Restore-Pfade, teure Vollkopien für CI.
Point-in-Time-Restore. Lakebase hält jede Datenversion innerhalb eines konfigurierbaren Restore-Windows von 2 bis 30 Tagen vor (Default 7 Tage). Ein Restore ist kein WAL-Replay, sondern ein neuer Branch zum gewünschten Zeitstempel, der sofort lesbar ist. Damit gehören Wiederherstellung nach versehentlichen Deletes und Audit-Auswertungen auf historische Stände zum Standard-Werkzeug, ohne separate Backup-Infrastruktur.
Ergänzend bietet Lakebase Read Replicas zum Skalieren von Leselast und eine High-Availability-Konfiguration mit automatischem Failover. Read Replicas und HA werden gegen Autoscaling und Scale-to-Zero abgewogen: Wer dauerhafte Verfügbarkeit braucht, verzichtet bewusst auf Scale-to-Zero. Welche dieser Funktionen in welcher Region und Cloud verfügbar ist und welche Postgres-Erweiterungen unterstützt werden, gehört vor dem ersten produktiven Einsatz gegen die Lakebase-Dokumentation geprüft.
Delta, Unity Catalog, Apps und Agents im Zusammenspiel
Lakebase bringt Anwendungsdaten in eine Plattform, in der bisher vor allem Analyse- und KI-Daten lagen. Delta-Tabellen bleiben die Grundlage für große Analysen, Reports und ML-Training. Unity Catalog (die Governance-Schicht für Daten und KI-Assets) verwaltet Berechtigungen, Datenherkunft und Klassifikationen. Lakebase ergänzt diese Architektur um eine Datenbank für schnelle transaktionale Zugriffe: Postgres-Storage im Databricks-Backend, sichtbar in Unity Catalog, mit einem vorgesehenen Datenaustausch zwischen Anwendungsdaten und Delta-Tabellen. Zwischen Delta und Lakebase laufen dafür Lakebase CDF und Synced Tables, während drei typische Konsumenten auf die Plattform zugreifen: ML-Modelle über Real-Time Feature Serving, KI-Agenten über Agent State und Databricks Apps über transaktionale Daten. Die Einbettung in die Lakehouse-Architektur bestimmt, wie sauber die Schicht im Betrieb läuft.
Lakebase ist vor allem für Anwendungen sinnvoll, die bereits direkt auf Databricks entwickelt werden. Databricks Apps sind dabei der erste Adressat: Jede App, die Einstellungen, Sitzungen oder Bearbeitungsstände speichern muss (User-Settings, Sessions, Vormerkungen, kleine transaktionale Schreibpfade), benötigt sonst eine zusätzliche Datenbank oder eine ungeeignete Speicherung in Delta-Tabellen. Ein weiterer wichtiger Anwendungsfall sind KI-Agenten. Ein Agent muss beispielsweise Sitzungen, Arbeitsschritte und Zwischenergebnisse speichern, und diese Daten gehören in eine OLTP-fähige Schicht. Delta-Tabellen sind für solche häufigen kleinen Änderungen nur bedingt geeignet. Lakebase bietet dafür einen passenden Speicher innerhalb derselben Plattform. Wie der gleiche Speicher Vektor- und Volltext-Suche als Lookup-Dienst bereitstellt, klären wir im Überblick zu Lakebase Search.
Der dritte Punkt ist Unity Catalog. Ziel ist, auch Lakebase-Daten über die gleichen zentralen Governance-Prozesse wie andere Databricks-Daten zu verwalten, mindestens in der Zielarchitektur. Beim Anlegen einer Tabelle in Lakebase werden Rechte über das Plattform-Modell vergeben, statt über klassische Postgres-Rollen. Das ist die zentrale Wirkung der Schicht: Ein gemeinsames Modell für Analyse- und Anwendungsdaten. Solange eine App-Datenbank außerhalb der Plattform stand, fehlte genau diese Klammer.
App-State, Agent-Memory, Online-Lookups und Workflow-Status
Vier Anwendungsfälle passen besonders gut zu Lakebase. Jedes davon hat in den letzten Plattform-Projekten konkret nach einer Lösung verlangt, die innerhalb der Plattform sitzt.
Anwendungsdaten für Databricks Apps
Benutzereinstellungen, gespeicherte Filter und Bearbeitungsstände, kleine Tabellen, die von der Anwendung regelmäßig gelesen und geändert werden. Lakebase kann diese Daten direkt innerhalb der Databricks-Plattform speichern.
Memory und Session Management für KI-Agenten
Ausgeführte Aktionen, Zwischenergebnisse und Gesprächsverläufe, kleine Vektor-Indizes. Wenn dieses Memory im Lakehouse-Kontext leben soll, ist Lakebase die natürliche Heimat mit denselben Zugriffs- und Auditregeln.
Schnelle Abfragen für ML- und KI-Anwendungen
Vorberechnete Merkmale mit sehr kurzer Antwortzeit brauchen oft einen Key-Value-Lookup. Eine gut indexierte Postgres-Tabelle über Lakebase deckt diesen Pfad ab, ohne einen weiteren spezialisierten Datenbankdienst einzuführen.
Status- und Steuerungsdaten aus Workflows
Statusänderungen, technische Metadaten und kleinere Freigabeprozesse aus Plattform-Workflows. Überschaubare Schreibvorgänge, klare Tabellenstruktur, Bedarf nach Konsistenz und Audit-Trail, klassisches OLTP-Profil im Kleinformat.
Was alle vier Profile verbindet, sind drei Eigenschaften: niedrige bis mittlere Schreib-Last, kurze Latenzen, hoher Wert auf Konsistenz und Governance. Genau auf dieses Profil ist Lakebase zugeschnitten.
Lakebase vs RDS, Azure Postgres und Delta: Welche Datenbank passt wann?
Entscheidend sind die Art der Nutzung, die erwartete Last und die Anforderungen an Governance.
| Achse | Lakebase | Externe Postgres (RDS / Azure DB / Cloud SQL) | Delta-Tabelle |
|---|---|---|---|
| Workload-Typ | Anwendungen mit vielen kleinen Lese- und Schreibvorgängen | Umfangreiche Anwendungsdatenbanken mit speziellen Erweiterungen und etabliertem Betrieb | Analysen, Reports und Verarbeitung großer Datenmengen |
| Latenz / Concurrency | Kurze Antwortzeiten bei einer mittleren Zahl gleichzeitiger Zugriffe | Kurze Antwortzeiten und ein langjährig erprobtes Skalierungsmodell | Hoher Datendurchsatz bei Analysen, aber nicht für einzelne schnelle Transaktionen optimiert |
| Governance | nativ in Unity Catalog, gemeinsames Berechtigungs-, Audit- und Lineage-Modell | Separate Verwaltung von Nutzern, Audit und Datenherkunft | nativ in Unity Catalog |
| Reife / Ökosystem | Noch vergleichsweise neu und mit wachsendem Funktionsumfang, Extensions-Lücken möglich | reif, große Extension-Bibliothek, große Operations-Community | reif für Analytics, etabliertes Tooling |
| Compute-/Kostenmodell | Nutzungsabhängige Abrechnung mit automatisch skalierter Rechenleistung | Feste oder reservierte Datenbankinstanzen mit eigener Größenplanung | DBU-basiert, gegen Lakehouse-Compute |
| Sync zu Lakehouse | erstklassiger Pfad zu Delta, Sichtbarkeit in Unity Catalog | Federation oder eigene Ingestion-Pipeline | nativ |
| Typische Heimat | Databricks Apps, Agents, App-State, Online-Features | Kern-Anwendungen mit etabliertem Postgres-Betrieb | Analytics, Reporting, ML-Training |
Die Tabelle erklärt eine wiederkehrende Beobachtung. Bei neuen Databricks Apps kann die zusätzliche Betriebs- und Governance-Schicht einer externen Datenbank schwerer wiegen als deren größerer Funktionsumfang. Eine separate RDS-, Azure-Postgres- oder Cloud-SQL-Instanz ist nicht Teil der Plattform: Nutzer, Rechte und Backups laufen über ein zweites Betriebsmodell, Lineage bricht an der Plattform-Grenze ab, und jede Anwendung muss ihren eigenen Sync-Pfad zum Lakehouse betreiben. Dieser Mehraufwand fällt für Lakebase weg, weil die Datenbank in Unity Catalog, Identity und Lineage sitzt. Eine etablierte produktive Postgres-Datenbank sollte dagegen nicht ohne konkreten Vorteil migriert werden. Und für analytische Workloads ist die Antwort weiterhin Delta. Lakebase eignet sich vor allem für neue transaktionale Anwendungen, die direkt auf Databricks entstehen.
Berechtigungen, Sync und Audit
Der größte Vorteil liegt in der engeren Verbindung mit der bestehenden Databricks-Governance. Lakebase-Tabellen tauchen in Unity Catalog auf, Daten können über vorgesehene Integrationen zwischen Lakebase und Delta ausgetauscht werden, und die Berechtigungen leben dort, wo sie für die Plattform ohnehin schon liegen. Dadurch müssen weniger getrennte Prozesse für Zugriffe, Audit und Datenaustausch betrieben werden.
Im Architektur-Entwurf entscheiden zwei Fragen, wie sauber das gelingt. Erstens: Welche Daten benötigt die Anwendung direkt und welche gehören in die Analyseplattform? Wann und in welche Richtung werden Daten zwischen beiden Bereichen übertragen? Wenn Anwendungsdaten zusätzlich für Reporting oder ML in Delta bereitgestellt werden, können Analyse- und KI-Workloads darauf zugreifen, ohne die operative Datenbank direkt abzufragen. Wenn der Abgleich zeitversetzt erfolgt, können Anwendung und Reporting vorübergehend unterschiedliche Datenstände zeigen. Diese Aktualitätsanforderung sollte vor der Umsetzung verbindlich festgelegt werden.
Zweitens: Wie werden Berechtigungen ausgerollt? Unity Catalog als Single Source bedeutet, dass Anwendungsteams Zugriffe möglichst über das zentrale Plattformmodell statt über separate Datenbankrollen verwalten sollen. Das ist eine Veränderung gegenüber der üblichen Verwaltung direkt in Postgres und entlastet das Team, das die Datenbank bisher als separates System betreibt. Im Gegenzug muss das Identity- und Group-Modell der Plattform sauber stehen, also wenn Nutzer, Gruppen und technische Identitäten bereits zuverlässig verwaltet werden, sonst kippt die Vereinfachung in die andere Richtung.
Der dritte Aspekt ist die Lineage. Eine Lakebase-Tabelle, die von einem Agent beschrieben und in einer Delta-Tabelle weiterverarbeitet wird, taucht im Lineage-Graphen als verbundener Knoten auf. Das ist im Audit der entscheidende Punkt: Ein möglichst durchgängiger Nachweis vom Anwendungszugriff bis zur weiteren Verarbeitung statt eines Sprungs von „App-Datenbank außerhalb der Plattform" zu „Daten im Lakehouse".
Was kostet Lakebase?
Lakebase verwendet ein anderes Kostenmodell als RDS, Azure Database for PostgreSQL oder Cloud SQL. Statt einer dauerhaft bereitgestellten Datenbankinstanz wird die Nutzung über Databricks-Verbrauchseinheiten abgerechnet. Speicherkosten werden zusätzlich berechnet. Databricks listet die aktuellen Tarife auf der Lakebase-Pricing-Seite und im Lakehouse-Pricing-Kontext; Preise unterscheiden sich nach Cloud, Region und Vertragsmodell und sollten vor der Architektur-Entscheidung gegen die tatsächliche Last gerechnet werden.
Drei Nutzungsprofile sind für den Kostenvergleich besonders wichtig. Erstens kann Lakebase wirtschaftlich sein, wenn die Datenbank nur zeitweise oder sehr unterschiedlich stark genutzt wird: Eine interne Anwendung, die hauptsächlich während der Arbeitszeit genutzt wird, ein KI-Agent mit zeitlich begrenzten Nutzungsspitzen, transaktionale Schreibpfade aus Workflows. Eine feste Cloud-Datenbank verursacht dagegen auch in ruhigen Zeiten laufende Kosten. Lakebase skaliert das Compute herunter.
Zweitens kann bei dauerhaft hoher Auslastung eine klassische Datenbank günstiger sein. Eine Datenbank, die rund um die Uhr unter Last steht, läuft auf reservierten oder langfristig gebuchten Datenbankinstanzen bieten dann häufig besser planbare Kosten. In den Vergleich gehören jedoch auch Betrieb, Backups, Monitoring, Zugriffsverwaltung und Bereitschaftsdienste. Diese internen Aufwände werden in einem reinen Preisvergleich häufig übersehen.
Drittens lohnt es sich, auch Entwicklungs- und Testkopien in den Kostenvergleich einzubeziehen. Lakebase erlaubt schnelle Datenbankkopien für Entwicklung und Tests, ohne den gesamten Datenbestand erneut zu speichern, was zusätzliche Datenbankinstanzen und vollständige Datenkopien vermeiden kann. Bei einer eigenen RDS-Instanz pro Stage zeigt sich hier eine direkte Konsolidierungs-Wirkung. Das ist gleichzeitig eine Kosten- und eine Betriebs-Frage: Weniger Unterschiede zwischen Umgebungen und weniger manueller Verwaltungsaufwand.
Mini-Kostenbeispiel: Lakebase auf Azure Germany West Central
Ein rechnerisches Beispiel auf Basis der aktuellen Premium-Listenpreise für Azure Germany West Central (Stand 06/2026): eine 50-GB-Datenbank, im Mittel 2 Compute Units. Die Listenpreise: $0,134 pro CU-Stunde im Autoscaling, $0,101 pro CU-Stunde als Always-On-Minimum (inklusive Cloud-Instance), $0,375 pro GB-Monat Storage. Bis 31.01.2027 läuft auf den Compute-Preis eine 50-%-Promotion, die im Beispiel separat ausgewiesen wird.
Szenario A: Autoscaling, interne App in Bürozeiten (8 Stunden × 22 Werktage = 176 aktive Stunden, Rest Scale-to-Zero):
- Compute: 2 CU × 176 h × $0,134 = $47,17
- Storage: 50 GB × $0,375 = $18,75
- Summe ≈ $66 / Monat (mit aktiver Promotion ≈ $42)
Szenario B: Always-On 24/7 (730 Stunden, keine Scale-to-Zero, ohne HA):
- Compute Always-On Minimum: 2 CU × 730 h × $0,101 = $147,46
- Storage: 50 GB × $0,375 = $18,75
- Summe ≈ $166 / Monat
Zum Vergleich: Eine ähnlich dimensionierte Azure Database for PostgreSQL Flexible Server (Burstable B2s, 2 vCPU, 4 GB RAM, 50 GB Storage) in derselben Region liegt nach Listenpreis bei rund $60–80 / Monat dauerhaft. Auf den ersten Blick wirkt die externe Postgres günstiger als die Always-On-Variante, gegen Lakebase im Bürozeiten-Profil ist sie etwa gleichauf. Im Vergleich gehören jedoch zusätzlich die Sync-Pipeline ins Lakehouse, ein separates Identity- und Rechte-Modell, eigene Backup- und Monitoring-Infrastruktur und der laufende Betrieb. Diese Kosten sind im Listenpreis nicht enthalten und kippen die Rechnung in der Praxis häufig zugunsten von Lakebase, sobald die Anwendung ohnehin im Databricks-Kontext lebt.
Wann bleibt eine externe Postgres die bessere Wahl?
Lakebase ist nicht für jede Datenbankanforderung die passende Lösung. Vier Konstellationen verlangen weiterhin nach einer externen Postgres oder einer anderen klassischen Cloud-Datenbank.
Geschäftskritische Datenbanken mit bewährten Betriebs- und Compliance-Prozessen. Eine Datenbank, die eine Hauptanwendung trägt, an der Replikation, Backup-Strategie, Compliance-Audits und ein eingespieltes Team hängen, sollte nicht allein wegen der engeren Databricks-Integration migriert werden.
Nicht unterstützte Postgres-Erweiterungen. Wenn die Anwendung auf PostGIS, TimescaleDB, spezifische Volltext-Erweiterungen oder eigene Custom-Funktionen aufbaut, deckt eine generische Postgres-Distribution mehr ab als ein vergleichsweise junger Service.
Dauerhaft sehr hohe Schreiblast und besonders große operative Datenbestände. Lakebase ist auf OLTP-Workloads im Kontext von Apps und Agents zugeschnitten. Eine Datenbank, die kontinuierlich hohe Schreibraten oder sehr große Tabellen mit besonderen Performance-Anforderungen trägt, benötigt häufig eine Datenbank, deren Instanzen, Replikation und Performance gezielt konfiguriert werden können.
Für Analysen kann die bestehende Datenbank weiterhin über Federation an Databricks angebunden werden: Databricks liest gezielt aus der bestehenden Postgres, ohne dass die Daten in die Plattform migriert werden müssen. Die App bleibt auf der Bestands-Datenbank, die Analytics greift über die Plattform-Schicht zu, und die externe Quelle kann dabei zumindest in die zentrale Datenübersicht und Lineage eingebunden werden.
Co-Existenz, Federation und schrittweiser Umstieg
Die meisten Unternehmen werden Lakebase zunächst parallel zu bestehenden Datenbanken einsetzen. Bestehende Kernsysteme bleiben auf ihrer bisherigen Datenbank, während neue Databricks-Anwendungen Lakebase nutzen können, und Federation hält die Brücke. Ein schrittweises Vorgehen kann aus drei Phasen bestehen.
Im ersten Schritt steht die Inventur. Welche Datenbanken laufen heute, welche Anwendungen, Lastprofile, Erweiterungen und Wiederherstellungsanforderungen bestehen, welche Anwendungen hängen daran. Diese Liste ist die Entscheidungsgrundlage. Ohne diese Informationen lässt sich eine Migration nicht belastbar bewerten.
Im zweiten Schritt wird für neue Databricks Apps und Agenten Lakebase zunächst als bevorzugte Option geprüft. Neue Databricks-Apps, neue Agents, neue transaktionale Workloads im Plattform-Kontext starten auf Lakebase, mit zentral verwalteten Identitäten und Zugriffsrechten und mit einem klar definierten Datenaustausch zum Lakehouse. Das senkt die Anzahl neuer externer Datenbank-Instanzen, ohne bewährte Produktivsysteme unnötig zu verändern.
Im dritten Schritt wird der Bestand bewertet. Welche bestehenden kleineren Datenbanken könnten durch Lakebase vereinfacht werden? Kandidaten sind typischerweise App-Datenbanken, die ohnehin in Richtung Databricks Apps wandern, oder Postgres-Instanzen für kleinere Workloads mit hohem Betriebsaufwand bei geringer Nutzung und überschaubaren Anforderungen. Geschäftskritische und stark spezialisierte Datenbanken bleiben zunächst auf ihrer bestehenden Plattform.
Federation ermöglicht währenddessen den geregelten Zugriff auf externe Bestandsdatenbanken. Solange einzelne Datenbanken außerhalb stehen, liest Databricks per Federation, und Unity Catalog zeigt die Tabellen im selben Katalog wie die Lakebase- und Delta-Tabellen. Das Lineage-Bild bleibt vollständig, ohne dass jede Datenbank migriert sein muss.
Grenzen von Databricks Lakebase
Lakebase ist für bestimmte Anwendungsfälle gedacht und kein Ersatz für jede Datenbank. Vier Grenzen gehören in jede Entscheidung mit hinein.
Weniger langjährige Betriebserfahrung als etablierte Cloud-Datenbanken
Verfügbarkeit, Erweiterungen, Monitoring und Betriebsfunktionen entwickeln sich weiter. Ein produktiver Einsatz braucht eine Verifikation der konkreten Funktionen gegen die Anforderungen statt Annahmen über angekündigte, aber noch nicht verfügbare Funktionen.
Postgres-Kompatibilität heißt nicht jede Postgres-Funktion
Standard-Treiber, Standard-SQL und gängige Tools funktionieren. Spezielle Erweiterungen, Replikationsverfahren und individuelle Datenbankfunktionen sind im Einzelfall zu prüfen.
Eignung hängt an Last, Datenmenge und Zugriffsverhalten
Dauerhaft sehr viele gleichzeitige Schreib- und Lesevorgänge, sehr große Tabellen mit spezifischen Performance-Profilen oder analytische Joins gehören entweder in eine externe Datenbank oder in Delta.
Governance-Vorteil braucht gepflegte Identitäten
Der Plattform-Vorteil von Unity Catalog als Single Source funktioniert nur, wenn das Identity- und Group-Modell ordentlich aufgesetzt ist. Ein unklarer Berechtigungsaufbau bleibt auch mit Lakebase ein Problem.
Diese Grenzen sind keine Argumente gegen Lakebase. Sie zeigen, unter welchen Voraussetzungen Lakebase sinnvoll eingesetzt werden kann. Wird sie offen benannt, fällt die Architektur-Entscheidung sauberer aus als bei einem pauschalen Einsatz als Postgres-Ablöse.
Fazit
Lakebase wird interessant, sobald Databricks Apps oder KI-Agenten dauerhaft Anwendungsdaten mit zentralen Zugriffs- und Auditregeln benötigen.
Lakebase wird besonders interessant, sobald Databricks Apps oder KI-Agenten dauerhaft Anwendungsdaten speichern müssen und eine transaktionale Datenbank mit zentralen Zugriffs- und Auditregeln benötigt wird. Dann verbindet Lakebase Analyseplattform und Anwendungsdaten innerhalb eines gemeinsamen Betriebsmodells. Eine zusätzliche externe Datenbank kann dadurch in geeigneten Fällen entfallen.
Besonders geeignet ist Lakebase für Unternehmen, die Databricks bereits als zentrale Daten- und KI-Plattform betreiben und mehrere Apps oder KI-Agenten produktiv einführen möchten. Typische Erkennungsbilder sind:
- Separate kleine Postgres-Datenbanken für einzelne Databricks-Anwendungen, in denen Anwendungsdaten und Zugriffsrechte außerhalb der zentralen Plattform verwaltet werden
- KI-Agenten, deren gespeicherte Daten bislang nicht in den zentralen Auditprozessen enthalten sind
- Viele einzelne Datenbanken mit jeweils eigenem Betrieb, Backup und Monitoring
- Ein Plattform-Team, das eine schnelle Bereitstellung vorberechneter Merkmale für ML-Anwendungen braucht, ohne einen separaten Key-Value-Store einzuführen
Mein Vorschlag: Lakebase bei neuen Databricks Apps und Agenten als bevorzugte Option prüfen und im selben Atemzug bestehende Datenbanken beibehalten, wenn ihre Anforderungen dort besser erfüllt werden. Federation ermöglicht weiterhin den Zugriff auf externe Bestandsdatenbanken, Unity Catalog kann die verschiedenen Datenquellen in einer gemeinsamen Governance-Sicht zusammenführen, und ein begrenzter Pilot sollte zeigen, ob Kosten, Performance, Backup und Betrieb den eigenen Anforderungen entsprechen.
Ziel ist nicht, möglichst viele Datenbanken durch Lakebase zu ersetzen. Ziel ist, Anwendungsdaten, Agenten-Gedächtnis und Analysedaten möglichst unter gemeinsamen Zugriffs-, Audit- und Betriebsregeln zu verwalten.
Lakebase oder eine andere Postgres-Variante?
- welche eurer geplanten oder bestehenden Apps und Agents zuerst auf Lakebase passen und welche Bestands-Datenbanken bewusst außen bleiben
- wie der Sync zwischen Lakebase, Delta und Unity Catalog konkret zu schneiden ist, damit Governance, Lineage und Audit zusammenhängen
- welcher Pilot- und Co-Existenz-Pfad sich für eure Plattform-Reife und eure Operations-Realität trägt
FAQ
Databricks Lakebase ist eine voll verwaltete, Postgres-kompatible OLTP-Datenbank, die in das Databricks-Lakehouse integriert ist. Sie läuft auf der Open-Source-Postgres-Engine, ist serverless, sichtbar in Unity Catalog und für transaktionale Workloads im Kontext von Databricks Apps und Agents gebaut. Storage und Compute sind entkoppelt, Bewegungen zu und von Delta-Tabellen sind erstklassiger Pfad.
