LTAP (Lake Transactional/Analytical Processing) ist ein von Databricks am Data+AI Summit 2026 vorgestelltes Architekturmodell, das den operativen Betrieb einer Anwendung (Bestellungen anlegen, Konten führen) und die Auswertung derselben Daten (Berichte, Dashboards, KI) auf einer gemeinsamen Datenablage zusammenführt. Zwei Motoren teilen sich denselben Datenschatz: einer für den laufenden Betrieb, einer für die Auswertung. Die klassische Kopier-Strecke zwischen operativer Datenbank und Auswertungsplattform soll damit entfallen.
Was ist LTAP?
LTAP ist kein eigenständiges Produkt und keine einzelne Datenbank, sondern ein Architekturmodell. Im Zielbild liegen die Daten aus dem laufenden Anwendungsbetrieb und die Daten für die Auswertung auf derselben zentralen Datenablage (dem sogenannten Lakehouse, einem gemeinsamen Objektspeicher für Roh- und Analyse-Daten). Lakebase, eine von Databricks verwaltete Postgres-Datenbank direkt im Databricks-Arbeitsbereich, übernimmt das operative Geschäft, also alles, was pro Vorgang eine Zeile schreibt oder liest (Bestellung, Kontostand, Nutzer-Session). Lakehouse und Lakehouse//RT übernehmen die auswertende Seite, also Abfragen über viele Datensätze hinweg für Berichte, Dashboards und KI-Trainings. Beide greifen auf denselben Datenbestand zu, der in offenen Speicherformaten (Delta Lake, Iceberg) vorliegt und damit nicht an einen Hersteller gebunden ist.
Der entscheidende technische Baustein ist eine Echtzeit-Konvertierung zwischen Zeilen- und Spaltenformat. Schreibvorgänge der OLTP-Engine sollen automatisch in eine spaltenorientierte Sicht im Objektspeicher übersetzt werden, sodass eine separate Replikations- oder CDC-Pipeline zwischen operativer Datenbank und Lakehouse entfällt. Die technische Grundlage dafür kam unter anderem durch die Mooncake-Akquisition von Databricks im Jahr 2025 ins Produkt.
Über beiden Engines 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 eine zweite Berechtigungs- und Audit-Welt aufmacht.
Der Status der Architektur ist zum Stand der Veröffentlichung gemischt. Lakebase ist seit dem 2. Februar 2026 allgemein verfügbar (GA), Lakehouse//RT seit dem 16. Juni 2026 in der Beta-Phase. Die gemeinsame Speicherebene mit Echtzeit-Konvertierung wird von Databricks als „coming soon" beschrieben; ein GA-Termin für die LTAP-Architektur im Vollausbau liegt nicht vor. Unabhängige Benchmarks unter produktionsrealistischer Last fehlen ebenfalls.
Abgrenzung gegen HTAP und Zero-ETL
LTAP positioniert sich gegen zwei etablierte Architekturkategorien, die dieselbe Fragestellung (OLTP und OLAP ohne klassische ETL-Strecke verbinden) auf andere Weise lösen.
| Ansatz | Engines | Speicher | Datenkopien |
|---|---|---|---|
| LTAP | zwei spezialisierte Engines | gemeinsamer Objektspeicher | konzeptionell keine, gemeinsamer Store noch angekündigt |
| HTAP | eine Engine für OLTP und OLAP | gemeinsamer Store, oft hybrides Layout | konzeptionell keine |
| Zero-ETL | zwei getrennte Engines | je Engine eigener Store | bleiben bestehen, Pipeline ist nur verborgen |
[HTAP](/insights/glossar/htap/) löst das Problem durch eine einzige Engine, die OLTP und OLAP auf demselben Datenbestand bedient, und nimmt dafür den Engine-Physik-Kompromiss zwischen Zeilen- und Spaltenformat in Kauf. [Zero-ETL](/insights/glossar/zero-etl/) lässt Engines und Stores getrennt und automatisiert nur die Pipeline dazwischen; die Datenkopie bleibt erhalten. LTAP trennt die Engines wie Zero-ETL, vereint aber die Speicher-Schicht und vermeidet so konzeptionell die Datenkopie. Der zentrale technische Unterschied liegt also weniger in der Engine-Schicht als auf der Storage-Ebene.
Beispiel: Databricks App mit KI-Agent auf Lakebase und Lakehouse
Eine Databricks App stellt einen Kunden-Assistenten zur Verfügung, der Bestellungen anlegt, Anfragen beantwortet und sich Konversationszustand merkt. Der operative State des KI-Agenten (welche Tools wurden aufgerufen, welche Konversation läuft, welcher Auftrag ist offen) liegt in einer Lakebase-Postgres-Datenbank. Anwendungs- und Bestelldaten liegen ebenfalls in Lakebase. Reports zu Antwortqualität, Lösungsquote und Bearbeitungszeit laufen auf denselben Tabellen über die Lakehouse-Engine.
Heute funktioniert die Trennung der beiden Engines bereits: Lakebase bedient die Anwendung und den Agenten, Lakehouse liefert die analytische Sicht, und Unity Catalog hält Berechtigungen für beide Seiten zusammen. Die Brücke dazwischen läuft heute noch über Replikation oder CDC. Im Zielbild von LTAP entfällt diese Brücke: Lakebase schreibt direkt in den gemeinsamen Objektspeicher, die analytische Sicht entsteht über die Echtzeit-Konvertierung der Storage-Schicht. Solange die gemeinsame Speicherebene nicht GA ist, bleibt dieses Zielbild ein Architekturversprechen, dessen Komponenten allerdings bereits einzeln nutzbar sind.
LTAP (Lake Transactional/Analytical Processing) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.