Databricks setzt $0 auf ETL: LTAP vereint OLAP und OLTP

Databricks trat auf seinem San Francisco Data + AI Summit – einer Veranstaltung mit inzwischen mehr als 30.000 Teilnehmern vor Ort – auf und kündigte drei Dinge an, die zusammengenommen darauf abzielen, eine gesamte Kategorie von Dateninfrastrukturausgaben zu eliminieren: ETL-Pipelines, spezialisierte Echtzeit-Serving-Stacks und eigenständige Customer Data Platforms. Die Kernzahl lautet 16x. Das ist der von Kunden gemeldete Maximal-Speedup des neuen Lakehouse//RT-Engines gegenüber bestehenden spezialisierten Echtzeit-Serving-Stacks – nach Darstellung von Databricks. Die zentrale Architekturbehauptung ist LTAP, das transaktionale und analytische Verarbeitung in einer einzigen, verwalteten Datenkopie zusammenführt.

Was passiert ist

Drei Ankündigungen landeten in derselben Keynote. Erstens: LTAP (Lake Transactional/Analytical Processing), eine neue Architektur, die Lakebase – beschrieben als serverloses Postgres auf offenem Objektspeicher – unter dieselbe Unity Catalog-Governance und Speicherschicht wie das Lakehouse stellt. Wie Blocks & Files berichtete, speichert LTAP Daten direkt in Unity Catalog in offenen Formaten, sodass es auf der Schreibseite mit jeder Postgres-fähigen Anwendung und auf der Analyseseite mit jedem Iceberg- oder Delta-Reader funktioniert. LTAP ist als Teil von Lakebase „demnächst verfügbar".

Zweitens: Lakehouse//RT, die Echtzeit-Ebene, angetrieben von einer neuen Compute-Engine namens Reyden. Databricks beansprucht Millisekunden-Abfragelatenz auf verwalteten Delta Lake- und Apache Iceberg-Tabellen, mit Unterstützung für Zehntausende gleichzeitiger Nutzer und Agenten. Kunden berichten von Antwortzeiten von nur 10ms bei kleineren Datensätzen, unter 100ms bei größeren und unter 100ms bei 12.000 Abfragen pro Sekunde auf Standard-Analyse-Benchmarks. Lakehouse//RT befindet sich im Beta-Stadium.

Drittens: CustomerLake, eine agentische Customer Data Platform, die nativ auf dem Lakehouse aufgebaut ist, aktuell in der Private Preview mit HP, Circle K, AB InBev und Getnet by Santander als genannten Kunden. Es ist Databricks' zweiter Vorstoß in einen definierten Enterprise-Softwaremarkt nach Lakewatch im Sicherheitsbereich, und es wird nach einem verbrauchsbasierten Modell statt einer klassischen Softwarelizenz bepreist.

CEO Ali Ghodsi rahmte das gesamte Paket in Agenten-Begriffen: „Unternehmen haben ihre Belegschaft effektiv verdoppelt – nur nicht mit Menschen. Agenten schreiben Code, führen Anrufe durch und laufen Schleifen in einem Tempo, das menschliche Teams niemals erreichen könnten." Sein Argument ist, dass Infrastruktur, die für menschliches Analysetempo gebaut wurde, nun der Flaschenhals ist. Lakebase, zur Einordnung, wurde erst letztes Jahr gestartet und meldet bereits Tausende von Kunden, darunter Block, Ensemble, Superhuman und Zillow, sowie 12 Millionen Datenbankstarts pro Tag.

Technische Analyse

Die interessante Engineering-Behauptung bei LTAP ist nicht „Wir haben HTAP gemacht." Viele Anbieter haben Single-Engine OLTP+OLAP versucht, mit gemischten Ergebnissen bei Isolation und Nebenläufigkeit. Databricks macht etwas Engeres und wohl Ehrlicheres: zwei Ausführungs-Engines behalten (Postgres für Transaktionen, den Lakehouse-Stack für Analysen), aber beide zwingen, eine einzige physische Datenkopie in Unity Catalog in offenen Tabellenformaten zu lesen und zu schreiben. Keine CDC-Pipeline, kein ETL-Job, keine Verzögerung durch eine zweite Kopie.

Wenn das unter Last standhält, verändert es das Kostenmodell an zwei Stellen. Erstens: Die Speicherkosten hören auf, sich für jeden Datensatz zu verdoppeln, der sowohl transaktionalen als auch analytischen Zugriff benötigt. Zweitens: Das Freshness-SLA für Analysen geht von „Minuten hinter der Produktion" zu „ist Produktion". Das ist im Vergleich zum vorherrschenden Muster zu sehen: Postgres oder MySQL, das Debezium oder Fivetran in Delta oder Snowflake speist, mit dbt-Transformationen nachgelagert. Dieser Stack funktioniert, aber er umfasst drei Anbieter und ein dauerhaftes Abstimmungsproblem.

Reyden, die Engine hinter Lakehouse//RT, ist das größere technische Fragezeichen. Das Versprechen lautet: Millisekunden-Latenz auf offenen Formaten bei 12.000 QPS, direkt auf Delta- und Iceberg-Tabellen, ohne proprietäres Format und ohne separaten Serving-Layer. Das bringt ihn in Konkurrenz zu ClickHouse, Pinot und Druid, die jahrelang genau auf dieses Latenzprofil optimiert haben. Die Quelle offenbart weder die Benchmark-Datensatzgröße, noch die Zeilenbreite, die Prädikat-Selektivität oder den Cache-Zustand – was wichtig ist, denn „unter 100ms bei 12.000 QPS" kann alles bedeuten von „triviale Punkt-Lookups auf warmem Cache" bis „komplexe Aggregationen auf kaltem Speicher". Bis Databricks einen reproduzierbaren TPC-H- oder ähnlichen Lauf mit diesen Zahlen veröffentlicht, ist die 16x-Kundenzahl richtungsweisend, kein Benchmark.

Die Lakebase-Ergänzungen sind der unterschätzte Teil: Cross-Cloud-, Cross-Region-Disaster-Recovery, Git-artiges Branching und Snapshots sowie autonome Datenbankoperationen, bei denen KI-Agenten den Zustand überwachen, Indizes vorschlagen und bei der Wiederherstellung helfen. Git-artiges Branching gegen Produktionsdaten ist das Feature, das Engineering-Teams tatsächlich am ersten Tag nutzen werden.

Wer unter Druck gerät

Die am stärksten exponierte Kategorie sind spezialisierte Echtzeit-Analyse-Anbieter. Wenn Lakehouse//RT auch nur annähernd den 16x-Wert gegenüber bestehenden Serving-Stacks liefert, wird die Beschaffungsfrage für Databricks-Shops unangenehm: Warum für eine zweite Engine, ein zweites Berechtigungsmodell und eine CDC-Pipeline zahlen, die es speist? ClickHouse, Pinot, Rockset-ähnliche Serving-Layer und die verschiedenen „Real-Time-OLAP"-Startups müssen alle formulieren, was sie tun, was Reyden nicht tut. Es ist noch nicht bekannt, wie Reyden sich bei High-Cardinality-Joins oder bei Workloads mit starken Mutationen verhält, und die Grenze dort ist wichtig: Wenn es bei dem Punkt-Lookup-intensiven Workload, der Product-Analytics-Dashboards antreibt, degradiert, reduziert sich die 16x-Behauptung auf ein enges Segment.

Die nächste Kategorie sind eigenständige CDP-Anbieter. CustomerLake ist ein direkter Angriff auf Segment, mParticle, Treasure Data und die Aktivierungsebene von Adobe und Salesforce. Die Formulierung „Infinity Campaigns" – kontinuierliche agentische Schleifen, die 1:1 eine Milliarde Mal täglich personalisieren – ist Marketingsprache, aber das architektonische Argument darunter ist solide: Wenn Kundendaten bereits im Lakehouse leben, ist es unsinnig, eine CDP anzuflanschen, die sie wieder herauskopiert. Dass Unternehmen wie AB InBev und HP als Kunden genannt werden, signalisiert, dass Databricks CDP-Budgets bei den Global 2000 anvisiert, nicht den Mittelstand.

iGaming- und Fintech-Teams sollten das aufmerksam verfolgen. Beide Branchen betreiben heißes OLTP (Wetten, Transaktionen, KYC-Events), das hungrige Analysen speist (Betrugsmodelle, Risiko-Dashboards, Personalisierung). Das aktuelle Muster ist Postgres oder Aurora plus eine Streaming-Pipe zu einem Warehouse. LTAP, wenn es das Isolationsversprechen einhält, entfernt die Streaming-Pipe. Das Unbekannte ist die Nebenläufigkeit unter den Audit-Anforderungen regulierter Workloads: Die Quelle sagt nicht, wie Unity Catalog Audit-Logs bei anhaltenden transaktionalen Schreibraten skalieren – und das ist die Frage, die ein Fintech-CISO als erstes stellen wird.

Handlungsempfehlungen für Data Teams

Diese Woche: drei konkrete Schritte. Erstens, prüfen Sie, wie viele Kopien Ihrer heißesten Kunden- oder Transaktionstabellen in Ihrem Stack existieren. Zählen Sie den OLTP-Primary, jedes Replikat, jeden CDC-Sink, jede Warehouse-Kopie und jeden Reverse-ETL-Endpunkt. Diese Zahl ist Ihr LTAP-Business-Case. Wenn sie vier oder höher ist, rechtfertigen allein die Speicher- und Abstimmungseinsparungen einen Piloten.

Zweitens, migrieren Sie die Produktion nicht zu Lakehouse//RT Beta oder LTAP „demnächst verfügbar". Bauen Sie stattdessen ein paralleles Messgerüst. Wählen Sie ein Echtzeit-Dashboard oder einen kundenseitigen Feature-Flag-Service, spiegeln Sie den Workload und messen Sie p50, p95 und p99-Latenz auf Reyden gegenüber Ihrem aktuellen Serving-Layer mit Ihren Daten, nicht mit Databricks' Benchmark-Daten. Die 16x sind eine von Kunden gemeldete Obergrenze. Ihre Zahl wird anders sein und ist die einzige, die zählt.

Drittens, wenn Sie heute eine CDP betreiben, fragen Sie Ihr Account-Team nach dem Migrationspfad, bevor CustomerLake die Private Preview verlässt. Die Preisgestaltung ist verbrauchsbasiert statt per Seat lizenziert, was die TCO-Modellierung anspruchsvoll macht. Holen Sie sich eine Nutzungsschätzung auf Basis Ihres tatsächlichen Event-Volumens, bevor das GA-Preisblatt feststeht.

Wenn LTAP und Reyden bei der behaupteten Performance standhalten, sollten wir innerhalb der nächsten zwei Quartale mindestens eine Ankündigung eines größeren spezialisierten Echtzeit-Analyse-Anbieters über eine Databricks-native Integration oder eine wettbewerbsfähige Preisanpassung sehen. Wenn bis Ende 2026 weder das eine noch das andere passiert, ist das das Signal, dass die technischen Behauptungen enger sind als die Keynote vermuten ließ.

Wichtigste Erkenntnisse

• LTAPs eigentliche Innovation ist eine einzige physische Datenkopie unter Unity Catalog, bei der Postgres- und Lakehouse-Engines denselben Speicher lesen. Kein CDC, kein ETL, keine zweite Kopie.
• Lakehouse//RT beansprucht unter 100ms bei 12.000 QPS und bis zu 16x Speedup gegenüber bestehenden Echtzeit-Serving-Stacks, aber Benchmark-Datensatz, Abfragemix und Cache-Zustand werden nicht offengelegt.
• Lakebase wuchs innerhalb eines Jahres vom Start auf Tausende von Kunden und 12 Millionen Datenbankstarts pro Tag, darunter Block, Superhuman und Zillow.
• CustomerLake (Private Preview, HP, Circle K, AB InBev, Getnet) ist Databricks' zweiter Vorstoß in vertikale Software nach Lakewatch, verbrauchsbasiert statt per Seat bepreist.
• Testbare Vorhersage: Wenn Reydns Behauptungen standhalten, ist innerhalb von zwei Quartalen eine Databricks-native Integration oder Preisanpassung von mindestens einem spezialisierten Echtzeit-Analyse-Anbieter zu erwarten.