Operative Datenbanken und Analytics ohne ETL: Was LTAP bei Databricks heute liefert
Die Kernaussagen auf einen Blick.
- LTAP steht für Lake Transactional/Analytical Processing und beschreibt Databricks' Zielbild für operative Datenbanken und Analytics auf einer gemeinsamen Datenbasis: Lakebase übernimmt neue transaktionale Workloads, Lakehouse//RT soll schnelle Analytics liefern, Unity Catalog hält Berechtigungen und Nachvollziehbarkeit zusammen.
- Heute verfügbar sind einzelne Bausteine wie Lakebase, Lakehouse und Unity Catalog; die gemeinsame Speicherebene mit schneller Umwandlung zwischen Zeilen- und Spaltenformat bleibt vorerst Roadmap.
- Für bestehende CDC-Strecken gilt: Neue Apps und KI-Agenten können punktuell auf Lakebase starten, bestehende produktive App-Datenbanken mit Debezium, Fivetran oder Qlik sollten aber nicht vorschnell migriert werden, solange LTAP unter realer Last nicht belegt ist.
Inhaltsverzeichnis
LTAP ist noch mehr Ankündigung als Produkt
In vielen Architekturgesprächen sieht das Bild ähnlich aus. Auf der einen Seite steht das Lakehouse mit Unity Catalog. Daneben läuft eine produktive Postgres in RDS, auf der die Anwendung arbeitet. Dazwischen läuft eine CDC-Strecke mit Debezium, die regelmäßig Pflege, Monitoring und Fehlerbehebung braucht. Parallel steht in der Presse, Databricks mache ETL zwischen operativer Datenbank und Lakehouse überflüssig.
Diese Konstellation entsteht immer wieder, sobald App-Datenbank und Lakehouse parallel betrieben werden. Mit jeder neuen Anwendung kommt häufig eine weitere CDC-Pipeline dazu, der Zustand neuer KI-Agenten landet oft in einer weiteren Postgres-Instanz, und Berechtigungen für operative Daten werden getrennt von Unity Catalog gepflegt. Wenn Databricks dafür ein neues Architekturmodell vorstellt, stellt sich sofort die Frage:
Was steht heute schon produktiv hinter dem Begriff? Was ist noch Ankündigung? Sollen neue Anwendungen schon auf Lakebase und LTAP ausgerichtet werden, oder pflegen wir die CDC-Pipelines weiter? Welche Investitionen in Debezium, Fivetran oder Qlik könnten später wegfallen? Und welche Entscheidung bindet uns heute schon stärker an Databricks?
LTAP besteht heute aus nutzbaren Bausteinen und einem angekündigten Gesamtbild. Wer beide Seiten nicht sauber trennt, überschätzt entweder die Ankündigung oder unterschätzt die nutzbaren Bausteine.
Was ist LTAP?
LTAP steht für Lake Transactional/Analytical Processing. Databricks beschreibt damit ein Architekturmodell, in dem zwei spezialisierte Engines auf demselben Objektspeicher arbeiten: eine Postgres-Engine für transaktionale Anwendungen (Lakebase) und eine Analyse-Engine für Reports, Dashboards und ML (Lakehouse, dazu Lakehouse//RT für Sub-Sekunden-Queries). Beide sollen auf derselben Speicherebene arbeiten, in der die Daten in offenen Formaten wie Delta Lake und Iceberg liegen. Eine schnelle Umwandlung zwischen Zeilen- und Spaltenformat soll dafür sorgen, dass operative und analytische Sicht ohne separate Kopierstrecke verfügbar sind. Die Governance bleibt einheitlich, weil Unity Catalog Berechtigungen und Nachvollziehbarkeit für beide Seiten zusammenhält. Databricks beschreibt LTAP als „One Copy" für Transaktionen und Analysen.
Der Begriff beschreibt eine Antwort auf zwei bekannte Probleme. HTAP (Hybrid Transactional/Analytical Processing) versucht seit Jahren, OLTP und OLAP in einer einzigen Engine zu lösen, und stößt an den Zielkonflikt zwischen schnellen Schreibvorgängen und schnellen Analysen. Zero-ETL-Integrationen wie Aurora→Redshift oder OneLake-Mirroring verstecken einen Teil der Pipeline, behalten aber meist getrennte Datenbestände.
Ein wichtiger Treiber für LTAP sind KI-Agenten und neue Anwendungen. Databricks beziffert den Anteil agentisch erzeugter Datenbanken bei eigenen Kunden auf rund 80 Prozent der täglich rund 12 Millionen Lakebase-Launches; das ist eine Herstellerangabe ohne unabhängige Bestätigung, zeigt aber, warum Databricks dieses Architekturmodell nach vorne stellt. Agenten brauchen frische operative Daten und kurze Datenbank-Lebenszyklen mit Branch und Verwerfen. Für solche Workloads sind replizierte Daten aus klassischer CDC oft nicht frisch genug.
Das Zielbild ist klar: keine CDC-Strecke zwischen operativer Datenbank und Lakehouse mehr, weil beide Engines dieselbe Datei lesen. Solange LTAP nicht allgemein verfügbar ist, bleibt das aber ein Zielbild. Wie das Lakehouse-Architekturbild insgesamt funktioniert und welche Komponenten dort heute schon sitzen, zeigen wir im Überblick zur Databricks Data Intelligence Platform.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was ist der Unterschied zwischen LTAP, HTAP und Zero-ETL?
Drei Architekturansätze versuchen, dasselbe Problem zu lösen, setzen aber unterschiedlich an. Für die Einordnung sind vier Fragen wichtig: Anzahl der Engines, gemeinsamer Store, bleiben Datenkopien bestehen, Reifegrad.
| Frage | HTAP | Zero-ETL | LTAP |
|---|---|---|---|
| Engines | eine Engine für OLTP und OLAP | zwei getrennte Engines, je eigener Store | zwei Engines, gemeinsamer Store |
| Speicherebene | proprietär, eine Engine bestimmt das Datenformat | je Engine eigener Store | geteilter Objektspeicher, Delta/Iceberg |
| Datenkopien | konzeptionell keine, real schwer trennbar | bleiben bestehen, Pipeline wird versteckt | konzeptionell keine, gemeinsame Speicherebene noch angekündigt |
| Reifegrad | etabliert, seit ~2014 | produktiv bei AWS, Microsoft, Snowflake | angekündigt, Komponenten teils GA |
| Typische Vertreter | SingleStore, TiDB, SAP HANA | Aurora→Redshift, OneLake-Mirroring, Snowflake Unistore | Databricks Lakebase + Lakehouse + Lakehouse//RT |
| Wann passend | mittlere Last für Transaktionen und Analysen in derselben Engine | bestehende Plattformen ohne größeren Architekturumbau | neue Anwendungen und KI-Agenten auf einer gemeinsamen Datenbasis |
HTAP steht für Hybrid Transactional/Analytical Processing und versucht, transaktionale und analytische Workloads in einer einzigen Datenbank-Engine zu vereinen. Diese Engine muss schnelle Schreibvorgänge und große analytische Abfragen gleichzeitig gut bedienen und muss dabei Kompromisse eingehen. Reynold Xin (Databricks) hat das am Data+AI Summit knapp benannt: eine Engine sei „zwangsläufig kompromissbehaftet". Im Databricks-Engineering-Post zu LTAP nennt er drei Ursachen: HTAP-Engines bleiben beim Feature-Umfang hinter spezialisierten OLTP- und OLAP-Engines zurück, das Ökosystem an Werkzeugen um sie herum ist dünner, und Transaktionen und Analysen teilen sich dieselben Ressourcen, was Performance-Trennung verhindert. Daraus leitet Databricks die Trennung der beiden Engines ab.
Zero-ETL beschreibt Ansätze, bei denen die ETL-Pipeline zwischen operativer Datenbank und analytischem System vom Plattform-Anbieter automatisiert und vor dem Nutzer verborgen wird. Die Pipeline wird damit für Nutzer weniger sichtbar, aber die Daten liegen weiterhin doppelt: einmal in der operativen Datenbank, einmal im analytischen Store. Snowflake Unistore und Hybrid Tables sind die nächstgelegenen Vergleichspunkte; sie verbergen die Konvertierung, behalten aber proprietäre Snowflake-Formate.
LTAP unterscheidet sich vor allem an einer Stelle: der gemeinsame Objektspeicher. Wenn Lakebase und die analytische Engine wirklich auf derselben Datenbasis arbeiten, muss zwischen beiden nichts mehr repliziert werden. Der Unterschied zu CDC hat eine handfeste Konsequenz für den Katalog: Klassische CDC-Strecken (Postgres publiziert Änderungen über ein CDC-Tool, einen Message Broker und einen Ingestion-Prozess in ein Data Warehouse mit gespiegelten Tabellenkopien) kosten Compute pro Tabelle, deshalb wählen Teams aus, welche Tabellen ins Lakehouse fließen, und alles andere bleibt außerhalb der Analytik. Die Pipeline erzeugt zudem Verzögerung zwischen Schreibvorgang und Auswertung. In LTAP entfällt diese Auswahl, weil jede Lakebase-Tabelle ohne Registrierung in der analytischen Sicht liegt.
Warum Databricks OLTP und OLAP zusammenführt
Transaktionen und Analysen stellen sehr unterschiedliche Anforderungen. OLTP-Workloads schreiben viele kleine Änderungen, lesen gezielt einzelne Datensätze und brauchen geringe Latenz pro Operation. Typisch sind ERP-Systeme mit Bestellungen und Lagerbeständen, E-Commerce-Backends mit Warenkorb und Login-Session oder die Buchungs-Datenbank hinter einer App. OLAP-Workloads lesen große Datenmengen, aggregieren über wenige Spalten und brauchen hohen Durchsatz pro Abfrage. Typisch sind Quartalsreports über die Vertriebsperformance, Kundensegmentierungen mit Millionen Datensätzen oder ML-Trainings auf historischen Verkaufsdaten. Zeilenorientiertes Storage-Layout bedient den ersten Fall, spaltenorientiertes Storage-Layout den zweiten. Eine Engine, die beides gleichzeitig optimal löst, gibt es praktisch nicht; HTAP-Systeme versuchen das seit 2014 und müssen bei beiden Profilen Abstriche machen.
LTAP zieht daraus die Konsequenz und trennt die Engine-Schicht: Lakebase liefert zeilenorientiertes OLTP für Anwendungsdaten, Agenten-Zustand und transaktionale Workloads, die Lakehouse-Engines liefern spaltenorientiertes OLAP für Reports, Dashboards und Machine Learning. Der entscheidende Schritt liegt darunter: beide sollen dieselbe Datenbasis nutzen. Beide Engines arbeiten auf demselben Lakehouse-Objektspeicher; Lakebase schreibt direkt hinein, und eine schnelle Umwandlung erzeugt parallel eine spaltenorientierte Sicht für die Analyse-Engines. Eine separate Storage-Replikation entfällt damit. Im Zielbild müssen die Daten nicht mehr über eine separate Pipeline kopiert werden.
Lakebase, Lakehouse//RT und Unity Catalog: was ist heute verfügbar?
LTAP im vollständigen Ausbau ist noch nicht allgemein verfügbar. Drei Bausteine sind heute schon relevant.
Lakebase
Verwaltete Postgres-Datenbank im Databricks Workspace, seit 2. Februar 2026 GA, seit 12. März 2026 mit Autoscaling.
Lakehouse//RT
Real-Time-Engine für Sub-Sekunden-Queries auf Delta-Tabellen, seit 16. Juni 2026 in der Beta-Phase.
Unity Catalog
Verbindet Lakebase- und Lakehouse-Tabellen unter einem gemeinsamen Berechtigungs- und Audit-Modell.
Lakebase ist seit dem 2. Februar 2026 allgemein verfügbar. Microsoft Learn dokumentiert sie als verwaltete Postgres-Datenbank im Databricks Workspace, die auf der Open-Source-Engine läuft, Speicher und Rechenleistung getrennt skaliert und in Unity Catalog eingebunden ist. Seit dem 12. März 2026 entstehen neue Instanzen standardmäßig als Autoscaling-Projekte; die Compute-Schicht passt sich ohne Neustart und ohne Verbindungsabbruch der Last an. Branches und Snapshots helfen bei Experimenten mit KI-Agenten und neuen Anwendungen: Ein Agent kann eine Datenbank in Sekunden klonen, ein Datenmodell ausprobieren und die Branch wieder verwerfen, ohne dass eine produktive Instanz angefasst wird. Databricks kommuniziert für die Storage-Compute-Trennung gegenüber klassischen Postgres-Monolithen fünffach höheren Schreibdurchsatz und halbierte Leselatenz sowie mehr als zehnfache Kompression beim Übergang in das spaltenorientierte Format (Databricks-Engineering-Post); das sind Herstellerangaben ohne unabhängige Bestätigung. Der klassische Monolith bündelt dazu im Vergleich Query Engine, WAL (Write-Ahead-Log) und Datendateien auf einer Maschine, während Lakebase Postgres-Compute von der Speicherebene trennt und Schreib- und Lesepfad in SafeKeeper und PageServer auslagert; die Datenseiten selbst liegen im Cloud-Objektspeicher.
Cloudübergreifende Wiederherstellung im Notfall (Disaster Recovery) zählt zu den weiteren Funktionen, die Databricks als Lakebase-Funktion beschreibt. Lakebase ist heute der OLTP-Baustein für neue Databricks Apps, KI-Agenten und transaktionale Workloads, die in der Plattform entstehen.
Lakehouse//RT ist seit dem 16. Juni 2026 in der Beta-Phase. Die Engine zielt auf Abfragen unter einer Sekunde direkt auf Delta-Tabellen, ohne ein zusätzliches OLAP-System daneben. Databricks beschreibt das als „Real-Time Performance on a Unified Lakehouse" und kommuniziert eine Latenz unter 100 Millisekunden bei 12.000 Queries pro Sekunde. Lakehouse//RT ist die analytische Seite, die LTAP für schnelle Analytics interessant macht.
Unity Catalog verbindet beide Seiten bei Governance. Berechtigungen, Datenherkunft und Audit gelten für Lakebase-Tabellen genauso wie für Delta-Tabellen im Lakehouse. Ohne diese gemeinsame Governance würde aus Lakebase und Lakehouse wieder eine getrennte Zwei-System-Landschaft entstehen, sobald die zweite Compute-Engine ihre eigenen Berechtigungen mitbringt.
Wann sich Lakebase als managed Postgres im Lakehouse für eine konkrete Anwendung lohnt, klären wir im Überblick zu Databricks Lakebase.
gemeinsame Speicherebene und schnelle Umwandlung
Der zentrale LTAP-Baustein ist die enge Verbindung von Lakebase und Lakehouse. Genau hier liegt aber noch der offene Punkt: Databricks beschreibt LTAP als kommenden Bestandteil von Lakebase, nennt bisher jedoch keinen GA-Termin. Damit ist die schnelle Umwandlung von Schreibvorgängen in Lakebase in eine analytische Sicht im Objektspeicher noch kein Baustein, auf den sich heute fest planen lässt.
Die technische Grundlage dafür kam unter anderem durch die Mooncake-Übernahme 2025 zu Databricks. Die Engine dahinter heißt Moonlink. Sie nutzt den Logical-Replication-Stream von Postgres und spiegelt Änderungen aus Lakebase in eine spaltenorientierte Analysesicht im Objektspeicher. Statt Daten erst über klassische ETL- oder CDC-Strecken aus der transaktionalen Datenbank ins Lakehouse zu bewegen, soll die Zeilen-zu-Spalten-Umwandlung direkt im Lakebase-nahen Pfad passieren.
Für aktuelle Daten nutzt Moonlink sogenannte Union Reads. Neue Änderungen liegen zunächst in einem spaltenorientierten Puffer im Arbeitsspeicher. Analytische Abfragen lesen dann bereits geschriebene Dateien, den Puffer und offene Änderungen als eine logische Tabelle zusammen. Dadurch sollen auch Daten sichtbar werden, die noch nicht in einem finalen Iceberg-Snapshot gelandet sind. Dieser Lesevorgang trennt Konsistenz und Aktualität sauber auf: Postgres liefert den aktuellen LSN als Zeitanker, der Objektspeicher liefert den materialisierten Großteil der Daten, und der PageServer liefert die letzten noch nicht materialisierten Änderungen. Die analytische Engine setzt beide Teile zu einer konsistenten Sicht zusammen.
Databricks konkretisiert das Konsistenz-Modell über die Log Sequence Number (LSN) von Postgres, also den Zähler, der jedem Schreibvorgang seine Position im Transaktions-Log gibt. Eine analytische Abfrage holt den aktuellen LSN aus Lakebase, liest den Großteil der Daten bis zu diesem Stand aus dem Objektspeicher und ergänzt nur die letzten, noch nicht materialisierten Änderungen aus einem Cache-Layer. Die Analyse sieht damit einen konsistenten Stand mit aktueller Datenlage, ohne dass Lakebase eine zusätzliche Analyse-Last tragen muss.
Bis dieser Mechanismus breit verfügbar ist, sollte LTAP vor allem als Architekturperspektive verstanden werden. Lakebase kann operative Anwendungen bedienen, die Analyse läuft aber weiterhin auf einer separaten Engine. Der Datenfluss dazwischen muss in vielen Setups also weiterhin über bestehende Integrations- oder Pipeline-Muster gelöst werden. Das Versprechen, die Pipeline zwischen App-Datenbank und Lakehouse deutlich zu vereinfachen, wird erst dann belastbar, wenn die Echtzeit-Konvertierung unter produktiver Last verfügbar ist.
Neue Anwendungen, KI-Agenten und transaktionale Workloads
Anwendungsdaten, Zustand von KI-Agenten, Konfigurationen, Session-Daten und kleinere transaktionale Tabellen, die innerhalb der Databricks-Plattform entstehen, sind gute Kandidaten für Lakebase. Die Architektur wird bei Berechtigungen und Audit einfacher, weil Unity Catalog die operativen Daten mitführt; eine separate Postgres-Instanz mit eigener Verwaltung kann entfallen. TheNewStack zitiert Databricks-Engineering dahingehend, dass Agenten ohne LTAP-Foundation gar nicht produktiv werden, weil die Aktualität der operativen Daten gegen Replikat-Latenz spielt.
Konkret heißt das: Wenn eine neue Databricks App gebaut wird oder ein KI-Agent operative Daten braucht, ist Lakebase ein sinnvoller OLTP-Baustein. Der State eines Agents (welche Tools er gerade getriggert hat, welche Branches er angelegt hat, welcher Konversationsstand vorliegt) gehört in eine Schicht, die unter demselben Berechtigungsmodell wie das analytische Lakehouse läuft. Branches und Snapshots bringen den Plattform-Vorteil noch näher an die Arbeitsweise von KI-Agenten: klonen, ausprobieren, verwerfen in Sekunden, ohne eine produktive Datenbank zu berühren.
Warum bleiben Debezium, Fivetran und Qlik vorerst?
Eine produktive Postgres in RDS, ein SQL Server oder eine Aurora-Instanz hinter einem ERP-System sollte nicht vorschnell nach Lakebase migriert werden, solange Erweiterungen, Lastprofile, Compliance-Vorgaben oder Wartungsfenster von der bestehenden Umgebung abhängen. Die CDC-Strecke ins Lakehouse bleibt vorerst bestehen; Debezium, Fivetran und Qlik bleiben Investitionen, die sich mittelfristig weiter nutzen lassen müssen. Die Architektur sollte so geplant werden, dass eine spätere Konsolidierung ohne harten Bruch möglich bleibt: Unity Catalog als zentrale Governance, offene Formate im Lakehouse, klare Trennung zwischen App-State und Analytik.
Gemeinsame Governance für operative und analytische Daten
Wenn Lakebase neben dem Lakehouse genutzt wird, ist die gemeinsame Governance-Schicht der wichtigste Punkt, der heute schon echten Nutzen bringt. Eine Lakebase-Instanz ohne Unity Catalog wäre wieder eine zweite Welt für Berechtigungen und Audit; sie würde die operative Vereinfachung mit neuer Governance-Komplexität bezahlen.
Unity Catalog übernimmt dabei drei Aufgaben: Berechtigungen für Lakebase-Tabellen genauso wie für Delta-Tabellen, Datenherkunft über operative und analytische Workloads hinweg, Audit-Spur für KI-Agenten, die operative Daten lesen oder verändern. Diese drei Funktionen waren bisher in zwei Welten organisiert: die App-DB mit eigenem RBAC, das Lakehouse mit Unity Catalog. LTAP zieht sie unter ein Modell zusammen.
Eine Governance-Schicht für beide Seiten: Permissions, Lineage, Audit.
Unity Catalog führt Berechtigungen, Datenherkunft und Audit-Spur für Lakebase- und Lakehouse-Tabellen in einem Modell zusammen.
Die Konsequenz für die Plattform ist klar. Lakebase-Schemata werden im selben Katalog registriert, in dem auch die analytischen Tabellen liegen. Nachvollziehbarkeit von Agent-Schreibvorgängen in Lakebase bis zur Auswertung im Dashboard wird durchgängig nachvollziehbar. Audit-Anforderungen aus EU-Regulatorik adressieren operative und analytische Daten in derselben Werkzeugwelt.
Was kostet LTAP?
Lakebase wird über Compute Units (CU, die Lakebase-Nutzungseinheit) mit Autoscaling abgerechnet, Lakehouse-Workloads werden über DBUs (Databricks Units, die Plattform-Nutzungseinheit) für SQL Warehouses oder Cluster abgerechnet. Beide Schichten laufen parallel und werden parallel budgetiert; das Argument „eine Plattform, eine Kostenstelle" reicht hier nicht aus.
Die FinOps-Sicht braucht zwei Kostenprofile mit unterschiedlichem Skalierungsverhalten. Lakebase skaliert nach Transaktions-Last, also vielen kleinen Schreib- und Lesevorgängen; Lakehouse skaliert nach Analyse-Last, also wenigen großen Abfragen. Die Kostenmodellierung muss beide Profile getrennt erfassen, sonst wird LTAP zu pauschal als Konsolidierung verkauft, obwohl weiterhin zwei unterschiedliche Kostenprofile entstehen.
Einsparungen entstehen auf der anderen Seite. Vorhandene CDC-Stacks (Debezium, Fivetran, Qlik) können in einer vollständigen LTAP-Architektur entfallen; die dort eingesparten Lizenz- und Betriebskosten müssen in die Vergleichsrechnung einfließen. Ein ehrlicher Business Case stellt Lakebase-CU plus Lakehouse-DBU einer realen RDS- oder Aurora-Stundenrate plus CDC-Lizenz plus Engineering-Aufwand für die Pipeline gegenüber. Erst dann zeigt sich, ob LTAP konsolidiert oder zwei Kostenwelten parallel erzeugt.
Wie unterscheidet sich LTAP von Snowflake Unistore, Fabric Mirroring und HTAP?
LTAP steht nicht allein. Drei etablierte Architektur-Ansätze verfolgen dasselbe Ziel, OLTP und Analytics näher zusammenzuführen, und setzen dafür jeweils anders an.
HTAP
Eine Engine für Transaktionen und Analysen: Kompromisse bei Feature-Tiefe, Werkzeug-Ökosystem und Ressourcentrennung.
Snowflake Unistore
Versteckt die Pipeline zwischen Transaktion und Analyse, hält Daten aber in proprietären Snowflake-Formaten.
Fabric Mirroring
Spiegelt operative Quellen in den Fabric-OneLake: Zero-ETL-Ansatz, die Datenkopie bleibt konzeptionell bestehen.
Klassische HTAP-Systeme (SingleStore, TiDB, SAP HANA) versuchen Transaktionen und Analysen in einer Engine zu lösen. Sie erreichen mittlere Transaktions- und Analyse-Last ohne separate Pipelines. Der Nachteil ist der technische Kompromiss: keine Engine optimiert OLTP und OLAP gleichzeitig. SingleStore und TiDB kritisieren Databricks' Begriffswahl; die Trennung der Speicherebene ist trotzdem der relevante Unterschied von LTAP zu HTAP.
Snowflake Unistore und Hybrid Tables verstecken die Pipeline zwischen Transaktion und Analyse innerhalb der Snowflake-Plattform weitgehend. Beide Workloads laufen auf separaten internen Engines, die Daten liegen in Snowflake-eigenen Formaten. LTAP unterscheidet sich an der Speicherebene: offene Tabellenformate wie Delta Lake und Iceberg, lesbar durch andere Engines. Abhängigkeit entsteht trotzdem, weil die schnelle Umwandlung Databricks-Engineering ist.
Microsoft Fabric Mirroring spiegelt Daten aus operativen Quellen (Postgres, SQL Server, Cosmos DB) in den Fabric-OneLake. Die operative Datenbank bleibt extern; nur die Pipeline wird vom Anwender entkoppelt. Das ist ein Zero-ETL-Ansatz in der Microsoft-Welt und behält die Datenkopie konzeptionell bei. LTAP entfernt die Kopie an der Speicherebene, weil Lakebase direkt in den Lakehouse-Objektspeicher schreibt.
Was in eigene Detailartikel gehört
LTAP verbindet mehrere Komponenten zu einem gemeinsamen Architekturbild. Wie sich der gesamte Databricks-Stack von Compute über Speicher bis Governance einordnet, zeigt der Databricks-Hub-Überblick. Wo eine OLTP-Schicht im Lakehouse heute sinnvoll ist und welche geeigneten Workloads dort hingehören, klären wir im Überblick zu Databricks Lakebase. Wie die analytische Seite ohne zusätzliches OLAP-System Latenz unter 100 Millisekunden erreicht, erläutern wir im Cluster zu Lakehouse//RT. Und wie sich die Datenebene insgesamt im Databricks-Stack einsortiert, von Compute-Schicht über Storage bis Governance, zeigen wir in der Databricks-Architektur-Übersicht. Wie das Datenlayout im Lakehouse mit Bronze-, Silver- und Gold-Schichten funktioniert, klären wir im Cluster zur Medaillon-Architektur. Eine kompakte Begriffsdefinition steht im Glossar-Eintrag zu LTAP.
Grenzen von LTAP bei Databricks
LTAP zeigt mehrere klare Grenzen, die vor jeder Plattform-Entscheidung benannt werden müssen.
Status und Nachweise
LTAP ist nicht GA, ein Termin fehlt. Unabhängige Benchmarks unter realistischer Produktionslast liegen für Lakehouse//RT bisher nicht in ausreichender Tiefe vor.
Abhängigkeit trotz offener Formate
Delta und Iceberg sind offen. Die Zeilen-zu-Spalten-Umwandlung auf der gemeinsamen Speicherebene ist Databricks-Engineering ohne dokumentierten Rückweg.
Postgres-Erweiterungen & Region
Lakebase unterstützt nicht jede Extension und ist nicht in jeder Region in voller Funktionstiefe verfügbar.
Bestehende CDC-Investitionen
Ein dokumentierter Migrationspfad mit Parallelbetrieb für Debezium, Fivetran oder Qlik fehlt bisher.
Status und belastbare Nachweise. LTAP ist nicht GA; ein konkreter Termin liegt nicht vor. Unabhängige Benchmarks unter realistischer Produktionslast fehlen. Databricks kommuniziert sub-100-Millisekunden-Latenz bei 12.000 Queries pro Sekunde für Lakehouse//RT, Perficient berichtet 86 Millisekunden Durchschnitt auf FHIR-Daten (Healthcare-Datenformat) als Validierung. StarTree argumentiert dagegen, dass 12.000 Queries pro Sekunde weit von realen Produktionsraten zwischen 100.000 und 200.000 entfernt liegen und P99-Latenzen, also die langsamsten ein Prozent der Anfragen, bisher nicht publiziert sind. Diese Größenordnung trifft allerdings vor allem kundennahe Echtzeit-Use-Cases wie personalisierte Empfehlungen, Real-Time-Pricing oder hochfrequentierte Web-Analytics. Klassisches internes BI-Reporting und die meisten Plattform-Workloads laufen mit deutlich weniger Anfragen pro Sekunde; dort reicht die kommunizierte Leistung in der Regel aus. Für eine kundennahe Anwendung mit hoher Anfragelast gilt: erst belastbare Zahlen unter eigener oder vergleichbarer Last prüfen.
Abhängigkeit trotz offener Formate. Delta und Iceberg sind offene Tabellenformate. Die schnelle Umwandlung zwischen Zeilen- und Spaltenformat auf der gemeinsamen Speicherebene ist Databricks-Engineering. Sie steht in keiner Spezifikation außerhalb der Plattform, und ein Migrationspfad zurück oder zu einer Drittengine auf demselben Layout ist nicht dokumentiert. Mit dem Einsatz von LTAP kommt das Gesamtpaket aus Databricks-Komponenten.
Postgres-Erweiterungen und Verfügbarkeit je Region. Lakebase basiert auf Open-Source-Postgres, unterstützt aber nicht jede Extension und ist nicht in jeder Region in voller Funktionstiefe verfügbar. Bestehende Datenbanken mit komplexen genutzten Erweiterungen sind keine Migrationskandidaten ohne Liste der fehlenden Funktionen.
Bestehende CDC-Investitionen. Bestehende CDC-Stacks mit Debezium, Fivetran oder Qlik könnten mittelfristig an Bedeutung verlieren. Einen dokumentierten Migrationspfad mit Parallelbetrieb und klaren Wechselkriterien gibt es bisher nicht. Wer heute investiert, plant für drei Jahre Restnutzung.
Fazit
LTAP bei Databricks ist heute zugleich nutzbare Architekturidee und noch nicht vollständig belegtes Versprechen.
Was davon für euch relevant ist, hängt von Workloads, Lastprofilen und Risikotoleranz ab. LTAP setzt zwischen HTAP und Zero-ETL an: zwei Engines für unterschiedliche Anforderungen, eine gemeinsame Datenbasis für operative und analytische Daten. Das ist die architektonisch saubere Antwort auf die lange bekannte Trennung zwischen operativer Datenbank und analytischer Plattform.
Heute produktiv einsetzbar sind Lakebase Postgres in der allgemeinen Verfügbarkeit, Lakehouse//RT in der Beta-Phase und Unity Catalog als verbindender Governance-Layer. Der gemeinsame Store mit Echtzeit-Transcodierung, der die drei Komponenten erst zu einer Architektur verbindet, ist als „coming soon" ausgewiesen und ohne unabhängige Nachweise unter echter Produktionslast.
Drei Entscheidungen sind heute sinnvoll: neue Apps und Agenten auf Lakebase aufsetzen, bestehende CDC-Strecken für produktive Datenbanken nicht vorschnell ablösen, Unity Catalog konsequent als gemeinsame Governance nutzen. So bleibt die Architektur offen, sobald LTAP allgemein verfügbar und unter realer Last belegt ist.
Mein Vorschlag: Lakebase punktuell für neue transaktionale Workloads einsetzen und den vollständigen LTAP-Umstieg erst eingehen, wenn unabhängige Benchmarks unter produktionsrealistischer Last vorliegen. Bis dahin ist der sinnvolle Weg: einzelne Bausteine nutzen, aber den vollständigen Umstieg nicht vorwegnehmen.
Ist LTAP der richtige nächste Schritt für euch?
- welche OLTP- und Analytics-Workloads gute Kandidaten für Lakebase und Lakehouse//RT sind
- welche Governance-, Lock-in- und Kostenrisiken vor dem nächsten Architektur-Schritt geprüft werden müssen
- wo Lakebase für neue Anwendungen sinnvoll ist und wo bestehende CDC-Strecken bleiben sollten und wie dieser Schnitt zu eurer Plattform passt
FAQ
LTAP steht für Lake Transactional/Analytical Processing. Databricks beschreibt damit ein Architekturmodell, in dem eine zeilenorientierte Postgres-Engine (Lakebase) und eine spaltenorientierte Analyse-Engine (Lakehouse, Lakehouse//RT) auf demselben Objektspeicher arbeiten. Datenkopien zwischen operativer Datenbank und Lakehouse sollen im Zielbild entfallen. Governance läuft über Unity Catalog, die Daten liegen in offenen Formaten wie Delta und Iceberg.
