Lakebase ist eine von Databricks verwaltete Postgres-Datenbank für laufende Anwendungen mit vielen kleinen Schreib- und Lesevorgängen pro Sekunde (fachlich: Online Transaction Processing, kurz OLTP). Sie speichert Betriebsdaten von Apps und KI-Agenten (Sitzungen, Zwischenstände, Gesprächsverlauf) direkt in Databricks. Zugriff und Berechtigungen laufen dabei über Unity Catalog, die zentrale Governance-Schicht von Databricks, die sonst auch das Lakehouse (die Analyseplattform) verwaltet. Databricks hat den Dienst am 2. Februar 2026 allgemein verfügbar gemacht.
Was ist Lakebase?
Lakebase ist eine OLTP-Engine, also eine Datenbank, die auf viele kleine Transaktionen ausgelegt ist. Im Unterschied zu einer Analyse-Datenbank, die große Datenmengen für Berichte durchrechnet, arbeitet Lakebase auf einzelnen Datensätzen. Technisch setzt sie auf PostgreSQL auf, dem verbreiteten Open-Source-Datenbanksystem. Speicher und Rechenleistung sind entkoppelt und lassen sich unabhängig voneinander skalieren; Databricks stellt die Instanzen bereit und übernimmt Patching, Backups und Skalierung. Für Anwendungen und KI-Agenten ist Lakebase über das übliche Postgres-Netzwerkprotokoll erreichbar, sodass bestehende Postgres-Werkzeuge und Datenbank-Bibliotheken (etwa Object-Relational Mapper wie SQLAlchemy oder Prisma) weiter funktionieren.
Der Dienst positioniert sich für transaktionale Workloads mit vielen kleinen Schreib- und Lesevorgängen: Databricks Apps, KI-Agenten mit Konversations-State und Tool-Historie, Online-Lookups, Feature-Serving mit niedriger Latenz sowie Statusdaten von Workflows. Eine bestehende produktive Postgres-Datenbank (RDS, Azure Postgres, Cloud SQL) ersetzt Lakebase nicht automatisch; die Passung hängt von Lastprofil, benötigten Postgres-Erweiterungen, Region und Compliance-Anforderungen ab.
Technisch geht Lakebase auf die Neon-Akquisition durch Databricks im Jahr 2025 zurück, die die Trennung von Storage und Compute in den Dienst gebracht hat. Über Lakebase liegt Unity Catalog als gemeinsame Governance-Schicht: Berechtigungen, Datenherkunft und Audit gelten für Lakebase-Tabellen genauso wie für Delta-Tabellen im Lakehouse. Damit soll vermieden werden, dass eine operative Datenbank neben dem Lakehouse ein zweites Berechtigungs- und Audit-Modell aufmacht.
Im [LTAP-Architekturmodell](/insights/glossar/ltap/) ist Lakebase die zeilenorientierte Engine, die neben dem spaltenorientierten Lakehouse (und Lakehouse//RT für Echtzeit-Analyse) auf einem gemeinsamen Objektspeicher arbeitet. Die gemeinsame Speicherebene mit Echtzeit-Konvertierung zwischen Zeilen- und Spaltenformat wird von Databricks als „coming soon" beschrieben; Lakebase selbst ist unabhängig davon nutzbar, die LTAP-Vollausbau-Architektur ist es noch nicht.
Abgrenzung gegen Lakehouse, LTAP und klassisches OLTP
Lakebase wird häufig mit dem Lakehouse verwechselt, weil beide Namen nah beieinander liegen und beide auf Databricks laufen. Beide bezeichnen aber grundlegend unterschiedliche Rollen in der Architektur.
| Begriff | Rolle | Workload | Speicherformat |
|---|---|---|---|
| Lakebase | OLTP-Engine im Databricks-Workspace | Transaktionen, App-State, Agent-Memory | zeilenorientiert (Postgres) |
| Lakehouse | OLAP-Plattform (Delta Lake, Unity Catalog) | Analyse, Reporting, ML | spaltenorientiert (Delta/Iceberg) |
| LTAP | Architekturmodell (Lakebase + Lakehouse gemeinsam) | OLTP und OLAP ohne klassische ETL-Strecke | zwei Engines, gemeinsamer Objektspeicher |
| Klassisches OLTP | eigenständige Postgres-DB (RDS, Azure Postgres) | Transaktionen, Anwendungsdaten | zeilenorientiert, außerhalb der Lakehouse-Governance |
Das [Lakehouse](/insights/glossar/data-lakehouse/) bedient analytische Workloads auf einem spaltenorientierten Delta- oder Iceberg-Store; Lakebase bedient transaktionale Workloads auf einer zeilenorientierten Postgres-Engine. Beide zusammen bilden den Engine-Teil des [LTAP-Modells](/insights/glossar/ltap/), das die klassische ETL-/CDC-Strecke zwischen OLTP- und OLAP-System durch eine gemeinsame Speicherebene ersetzen soll. Gegenüber einer klassischen externen Postgres-Datenbank ist der Hauptunterschied die Governance-Integration: Lakebase-Tabellen laufen in Unity Catalog, eine externe Postgres bringt ein zweites Berechtigungs- und Audit-Modell mit.
Beispiel: Konversations-State eines KI-Agenten in einer Databricks App
Eine Databricks App stellt einen Kunden-Assistenten bereit, der Anfragen beantwortet, Bestellungen anlegt und den Konversationsverlauf über mehrere Sitzungen hinweg merkt. Der operative State des Agenten (welche Konversation läuft, welche Tools wurden aufgerufen, welcher Auftrag ist offen) sowie die Sessions der Anwender liegen in einer Lakebase-Postgres-Datenbank. Zugriff, Verschlüsselung und Audit-Trail dieser Tabellen sind in Unity Catalog konfiguriert.
Reporting-Metriken (Antwortqualität, Lösungsquote, Bearbeitungszeit pro Anfrage) laufen parallel auf denselben Datenbestand über die Lakehouse-Engine, ohne dass für die analytische Sicht eine externe Replikations-Pipeline nötig wird. Solange die LTAP-Speicherebene mit Echtzeit-Konvertierung noch nicht GA ist, läuft die Brücke zwischen Lakebase und Delta-Tabellen für aggregierte Analysen über verwaltete Synchronisations-Mechanismen; die Anwendung selbst und der Agent arbeiten aber vollständig auf Lakebase.
Lakebase im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.