Lakehouse//RT: Wann Databricks schnell genug ist und wann ClickHouse, Druid oder Pinot nötig werden
Lakehouse//RT bei Databricks: Was Reyden, AUTO-Sizing und inkrementelles Autoscaling versprechen, und wann Druid, Pinot oder ClickHouse trotzdem nötig sind.
Die Kernaussagen auf einen Blick.
- Databricks hat mit (Beta seit Juni 2026) eine eigene Engine für sehr schnelle Abfragen direkt auf Lakehouse-Tabellen angekündigt. Databricks verspricht Antwortzeiten im einstelligen bis zweistelligen Millisekundenbereich bei tausenden parallelen Queries, ohne Daten vorher in eine separate Analyse-Engine zu kopieren.
- Damit verschiebt sich die bisherige Entscheidung „Lakehouse oder Druid, Pinot, ClickHouse?“. Eine zweite Engine wird in vielen Fällen weniger zwingend, bei extremen Anforderungen bleibt sie aber weiter sinnvoll.
- Die Kundenbeispiele sind stark (Bally's, Cisco, Enverus, PointClickCare, Magnite), sie stammen aber von Databricks selbst. Lakehouse//RT ist heute eine Read-Only-Beta, ein GA-Termin liegt nicht vor.
Inhaltsverzeichnis
Aktuelle Daten nützen nichts, wenn das Dashboard hängt
Die Daten kommen laufend an, die Lakehouse-Tabellen sind aktuell, die Plattform steht. Dann kommt in der Abstimmung die Frage aus dem Fachbereich: Warum lädt das operative Dashboard trotzdem 15 Sekunden? Schnell steht dann eine zusätzliche Analyse-Engine wie Druid, Pinot oder ClickHouse im Raum. Parallel wird Lakebase diskutiert. Seit Juni 2026 steht zusätzlich Lakehouse//RT auf dem Tisch, Databricks' eigene Real-Time-Engine. Dabei wird die wichtigste Frage oft zu spät gestellt: wie schnell die Anwendung wirklich antworten muss.
In wachsenden Datenplattformen entsteht diese Diskussion oft nebenbei. Streaming wird eingeführt, weil das Quellsystem Ereignisse laufend bereitstellt. Photon ist bereits aktiv, weil es in vielen SQL-Warehouse-Setups enthalten ist. Lakebase wird diskutiert, weil es als neue Option für operative Anwendungen sichtbar wird. Und jetzt kommt mit Lakehouse//RT eine weitere Komponente, die genau diese Lücke schließen soll, an der bisher Druid oder ClickHouse ins Spiel kamen.
Welche Antwortzeit muss der Anwendungsfall auch bei hoher Last zuverlässig erreichen? Wie viele Nutzer greifen gleichzeitig auf dieselbe Ansicht zu? Welche Art von Abfragen kommt hauptsächlich vor: aggregierte Reports, Filter auf große Tabellen, sehr schnelle Lookups in Anwendungen für externe Nutzer? Was bedeutet eine zweite Engine für Berechtigungen, Betrieb, Monitoring und Kosten?
Was ist Databricks Lakehouse//RT?
Lakehouse//RT ist eine Real-Time-Engine, die Databricks am 16. Juni 2026 als Beta angekündigt hat. Sie arbeitet direkt auf Lakehouse-Tabellen in Delta und Iceberg, läuft unter Unity Catalog für Berechtigungen und Nachvollziehbarkeit und braucht keine zusätzliche Datenkopie in eine separate Analyse-Engine. Die zentrale Komponente ist eine neue Ausführungsengine namens Reyden, ergänzt um zwei Compute-Mechaniken: AUTO-Sizing wählt die Grundgröße der Rechenleistung automatisch, inkrementelles Autoscaling fügt zusätzliche Knoten schrittweise hinzu, ohne die Kapazität sofort grob zu verdoppeln oder zu verdreifachen. Bei Leerlauf kann die Rechenleistung auf null herunterfahren.
Databricks nennt Antwortzeiten von zehn Millisekunden bei kleinen Datensätzen, unter hundert Millisekunden bei größeren Beständen, unter hundert Millisekunden auch bei rund zwölftausend Abfragen pro Sekunde. Gegen die bisherigen Auslieferungsschichten in Databricks selbst gibt Databricks bis zu sechzehnfache Beschleunigung an, die Kundenbeispiele aus der Preview reichen von fünffacher Beschleunigung bei Cisco im Threat Hunting bis zu hundertfacher Beschleunigung bei einzelnen Abfragen bei Enverus im Energiehandel. Bally's nennt Subsekunden-Antworten bei sechzig Terabyte Gaming-Daten und Millionen Transaktionen pro Tag, Magnite konsistent unter zweihundert Millisekunden für die Werbeauktions-Pipeline, PointClickCare im Healthcare-Umfeld zehnfache Beschleunigung bei ausgewählten Workloads. Die Beispiele sind stark, stammen aber von Databricks selbst. Die Produktseite zu Lakehouse//RT bündelt die offizielle Positionierung.
Cisco
5-fache Beschleunigung im Threat Hunting.
Enverus
Bis zu 100-fache Beschleunigung bei einzelnen Abfragen im Energiehandel.
Bally's
Subsekunden-Antworten bei 60 TB Gaming-Daten und Millionen Transaktionen pro Tag.
Magnite
Konsistent unter 200 ms für die Werbeauktions-Pipeline.
PointClickCare
10-fache Beschleunigung bei ausgewählten Healthcare-Workloads.
Wichtig für die Einordnung: Die Beta ist heute auf Leseabfragen beschränkt, also auf BI-Serving und ähnliche Anwendungen. Schreibpfade laufen wie bisher über Streaming Tables, Lakeflow Declarative Pipelines oder Lakebase. Ein GA-Termin wurde nicht öffentlich genannt. Databricks gewährt bis Januar 2027 ein Launch-Angebot mit dreißig Prozent Rabatt auf die Lakehouse//RT-Nutzung. Unabhängige Benchmarks unter realistischer Produktionslast fehlen.
Damit bleiben viele schnelle Analyse-Workloads in Databricks, Berechtigungen und Betrieb ebenfalls an einer Stelle. Die Frage „Wann brauche ich eine spezialisierte Analyse-Engine?“ stellt sich seltener, weg ist sie aber nicht. Wo die Architektur als Ganzes in die Plattform passt, ordnen wir im Überblick zur Databricks Data Intelligence Platform ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Drei Antwortzeitklassen helfen bei der Architekturentscheidung
Die pauschale Frage „Databricks oder Druid, Pinot, ClickHouse?“ führt selten zu einer guten Entscheidung. Entscheidend ist die Antwortzeit, die die Anwendung im Betrieb wirklich braucht. Für die erste Einordnung reicht eine einfache Einteilung in drei Klassen.
| Antwortzeitklasse | Typischer Anwendungsfall | Gleichzeitige Nutzung | Databricks-Baustein | Zweite Engine prüfen? |
|---|---|---|---|---|
| Sekundenbereich (1–15 s) | Operatives Dashboard mit regelmäßiger Aktualisierung, regelmäßige Management-Reports, BI-Aggregate | 10–200 Nutzer | SQL Warehouse Pro oder Serverless + Photon + Streaming Tables | Nein, Databricks reicht dafür ohne zusätzliche Engine |
| wenige hundert Millisekunden | operative Anwendung, Sales-Console, Personalisierung während der Nutzung, schnelle Feature-Lookups für ML-Modelle | 200–5 000 QPS | Lakehouse//RT für Leseabfragen + Lakebase für Schreib- und Lookup-Last + Photon-SQL + Model Serving | Selten, vor allem bei sehr spezialisierten Index-Strukturen |
| Einstellige Millisekunden unter hoher Last | Embedded Analytics in Endkunden-Apps, Fraud-Scoring mit globalem Lookup, externe Analyseoberflächen | 10.000+ gleichzeitige Nutzer | Lakehouse//RT als Kandidat (Beta-Test gegen das eigene Lastprofil) | Ja, vergleichend bewerten: spezialisierte Analyse-Engine (Druid, Pinot, ClickHouse, StarRocks) mit Delta-Sharing- oder Iceberg-Sync |
Diese Einteilung ist als Entscheidungshilfe gedacht. Die meisten internen Reporting- und Analysefälle liegen in der ersten Klasse, dort ist die Entscheidung meist einfach. Die zweite Klasse war bis vor wenigen Monaten die kritische Grenze für eine externe Engine, mit Lakehouse//RT verschiebt sich die Antwort: SQL Warehouses und Lakebase reichen für die meisten Profile, Lakehouse//RT erweitert das nach unten. Die dritte Klasse bleibt der echte Test. Lakehouse//RT zielt explizit auch auf dieses Profil, die Belege stammen heute aber überwiegend vom Hersteller.
Klasse drei betrifft vor allem Anwendungen mit vielen externen Nutzern: Embedded-Analytics-Plattformen in Endkunden-Apps, Fraud-Engine-Backends mit Millionen Anfragen pro Stunde, Marketing-Apps mit sehr vielen gleichzeitigen externen Nutzern. Hier ist der sinnvolle Weg eine messbare Anforderung, ein Beta-Test gegen den eigenen Workload und ein paralleler Vergleichswert mit einer etablierten Analyse-Engine.
Welcher Databricks-Ansatz für welche Antwortzeit?
Photon beschleunigt SQL-Abfragen und Datenverarbeitung. Photon ist eine vektorisierte Ausführungsengine für analytische Abfragen, die SQL- und DataFrame-Operationen auf großen Delta-Tabellen deutlich schneller ausführt als die klassische Spark-Ausführung. Microsoft Learn dokumentiert Photon als native vektorisierte Engine für SQL-Workloads. Wie stark Photon hilft, hängt vom Abfrage-Typ ab und ist bei stark individuell programmierten Python-Funktionen geringer. Für schnelle Auswertungen ist Photon dort relevant, wo große Tabellen schnell gefiltert, verknüpft oder aggregiert werden müssen und das Ergebnis innerhalb weniger Sekunden vorliegen soll. Wie sich die Engine pro Workload-Typ rechnet, zeigen wir im Überblick zu Databricks Photon.
SQL Warehouses liefern die Rechenleistung für BI-Tools, Dashboards und Anwendungen. Es gibt drei Varianten mit unterschiedlichem Betriebs- und Kostenmodell. Serverless startet schnell und passt die Kapazität automatisch an, Photon ist integriert. Es eignet sich besonders für viele kleinere Abfragen aus BI-Tools und Dashboards. Pro ist für planbare mittlere Last mit mehr Kontrolle über Größe und Skalierung gedacht. Classic bleibt für Sonderfälle mit speziellen technischen Anforderungen relevant. Mit Lakehouse//RT ergänzt Databricks eine weitere Option: serverless, AUTO-sizing für die Basis-Rechenleistung, inkrementelles Autoscaling, scale-to-zero in Leerlauf-Phasen, sekundengenaue Abrechnung über DBUs. Wie der Serverless-Layer in Lakeflow und Workflows passt, ordnen wir im Überblick zu Databricks Serverless ein.
Streaming Tables und Materialized Views halten Daten fortlaufend aktuell. Streaming Tables nehmen kontinuierlich neue Daten aus Kafka, Auto Loader oder anderen Quellen auf und schreiben sie in Delta-Tabellen. Materialized Views berechnen wichtige Kennzahlen vor und aktualisieren sie schrittweise. Beide laufen unter Lakeflow Declarative Pipelines (vorher Delta Live Tables) und greifen typischerweise über Debezium-basiertes CDC auf die Quellsysteme zu. Je nach Setup liegt die Aktualität im Sekunden- bis Minutenbereich. Wie Auto Loader, CDC, Structured Streaming und Lakeflow für produktive Pipelines ineinandergreifen, zeigen wir im Überblick zu Data Engineering auf Databricks.
Lakebase übernimmt operative Schreiblast und schnelle Lookups. Lakebase ist eine verwaltete Postgres-Datenbank mit Anbindung an das Lakehouse. Sie ist gedacht für viele kleine Schreibvorgänge, gezielte Einzelabfragen und schnelle Antworten bei kleinen Datenmengen. Lakebase und Lakehouse//RT decken unterschiedliche Pfade: Lakehouse//RT übernimmt die schnelle Leseabfrage auf analytischen Tabellen, Lakebase übernimmt operative Schreibvorgänge und sehr schnelle Lookups für Online-Features. Wann Lakebase passt und wann nicht, klären wir im Überblick zu Databricks Lakebase.
Lakehouse//RT arbeitet direkt auf Lakehouse-Tabellen. Die Engine (Reyden) ist für analytische Leseabfragen unter 100 Millisekunden bei vielen gleichzeitigen Anfragen gebaut. Sie nutzt die offenen Tabellenformate Delta und Iceberg direkt, ohne Daten in ein eigenes Format zu kopieren. Unity Catalog regelt Berechtigungen und Audit, BI-Werkzeuge wie Tableau, Power BI und Databricks SQL binden sich über native Connectoren an. In der Beta ist die Nutzung auf Lese-Workloads beschränkt; Schreiblast bleibt in Streaming Tables, Lakeflow oder Lakebase. Wie das Serving für analytische Apps ineinandergreift, zeigen wir im Überblick zu Databricks SQL.
Was diese Komponenten zusammenhält: Unity Catalog für Berechtigungen und Nachvollziehbarkeit, Delta als Format und automatische Optimierung der Dateistruktur. Diese Governance müsste bei einer externen Engine zusätzlich aufgebaut oder gespiegelt werden.
Wann bleiben Apache Druid, Apache Pinot, ClickHouse oder StarRocks sinnvoll?
Mit Lakehouse//RT braucht es eine externe Engine seltener als bisher. Die Nachteile bleiben dieselben, sie betreffen aber weniger Anwendungsfälle. Druid, Pinot, ClickHouse und StarRocks haben jeweils eigene Stärken, zielen aber auf dasselbe Profil: sehr schnelle Abfragen bei sehr vielen gleichzeitigen Nutzern, meist in Anwendungen für externe Kunden.
Apache Druid
Stark bei Zeitreihendaten und vorberechneten Aggregationen, p99 unter 100 ms. Schwäche: komplexe Verknüpfungen großer Tabellen, weniger flexibel als klassische SQL-Warehouses.
Apache Pinot
Sehr schnelle Filterabfragen auf großen Tabellen mit passenden Indizes, Echtzeit-Ingestion aus Kafka, p99 unter 50 ms. Schwäche: komplexe Joins und anspruchsvolle Aggregationen.
ClickHouse
Hohe Geschwindigkeit bei großen analytischen Abfragen, breite SQL-Abdeckung, schnelle Aggregationen. Schwäche: sehr viele gleichzeitige Nutzer auf denselben Pfaden brauchen sorgfältige Optimierung.
StarRocks
Wachsende Integration mit offenen Lakehouse-Tabellenformaten ohne zusätzliche Kopien, stark bei vielen gleichzeitigen Anfragen. Schwäche: geringerer Reifegrad, kleineres Ökosystem.
Wenn eine Engine direkt auf einem offenen Tabellenformat arbeiten kann, reduziert das einen Teil der Kopien. Auf einem Iceberg-fähigen Lakehouse lässt sich die zweite Engine auf das gemeinsame Tabellenformat setzen und vollständige Datenkopien vermeiden. Berechtigungen, Betrieb, Monitoring und Identitäten müssen trotzdem zusätzlich geregelt werden. Mit Lakehouse//RT entsteht ein vierter Kandidat genau in dem Profil-Korridor, den Druid und Pinot bisher exklusiv bedient haben. Welche Engine am Ende passt, entscheidet ein Lasttest mit dem eigenen Workload, kein Produktdatenblatt.
Die Kosten einer zweiten Engine bestehen nicht nur aus Lizenz und Infrastruktur. Es sind die Folgekosten, die das Kostenmodell sprengen: zusätzlicher Datenabgleich, ein zweites Berechtigungs- und Auditmodell, zusätzlicher Betrieb mit Monitoring und Updates, eine zweite Schemenpflege und eine zweite Zuordnung von Nutzern und Berechtigungen. Wer diese Zusatzkosten nicht gegen den echten Geschwindigkeitsgewinn rechnet, verschiebt das Problem nur in eine weitere Plattformkomponente. Mit Lakehouse//RT entfallen diese Zusatzkosten, wenn die Engine zum Workload passt. Damit holt Databricks auch in der Echtzeit-Analytik auf: Sie reiht sich als weiterer Baustein der Plattform neben Data Engineering, Data Science, ML/AI und Governance ein, ohne dass dafür ein separates Werkzeug nötig wird.
Wann eine Engine-Trennung im KI-Kontext lohnt (Online-Features, Model Serving), klären wir im Überblick zu Real-Time-ML auf Databricks.
Drei typische Fälle und die passende Architekturentscheidung
Klar wird die Entscheidung erst an konkreten Anwendungen. Die folgenden drei Beispiele zeigen, wie die Antwortzeitklassen angewendet werden können, mit Lakehouse//RT als zusätzlicher Option.
Vertriebsdashboard
Aktualisierung alle 15 Sekunden, rund 50 gleichzeitige Nutzer. Streaming Tables, Materialized Views und SQL Warehouse Pro/Serverless mit Photon reichen aus. Lakehouse//RT ist hier meist nicht nötig.
Betrugserkennung in Echtzeit
Einstellige bis niedrige zweistellige Millisekunden bei mehreren tausend Anfragen pro Sekunde. Lakebase liefert die Feature-Lookups, Model Serving die Inference, Lakehouse//RT die analytischen Abfragen auf größeren Mustern.
Externe Analyseoberfläche
p99 unter 50 ms bei zehntausend gleichzeitigen Nutzern auf Milliarden Datensätzen. Lakehouse//RT im Beta-Lasttest, parallel ein Vergleichswert mit ClickHouse, StarRocks oder Pinot.
Grenzen und offene Betriebsfragen
Lakehouse//RT verändert die Architekturentscheidung, beantwortet aber nicht jede Frage. Fünf Punkte sollten vor dem produktiven Einsatz geprüft werden.
Read-Only-Beta
Schreibpfade laufen weiter über Streaming Tables, Lakeflow Declarative Pipelines oder Lakebase. Anwendungen mit gemischten Lese- und Schreibanforderungen lassen sich nicht vollständig über Lakehouse//RT lösen.
Herstellerzahlen
Die genannten Zahlen, von sechzehnfacher Beschleunigung bis zu den Kundenbeispielen von Bally's, Cisco und Enverus, kommen aus dem Databricks-Blog. Unabhängige Benchmarks unter realistischer Produktionslast fehlen.
Sub-Sekunden-Aktualität
Streaming Tables refreshen kontinuierlich, die tatsächliche Aktualität hängt von Quelle, Auslöseintervall und Rechenleistung ab. Ein verlässlicher Sub-Sekunden-Refresh muss über den gesamten Pfad gemessen werden.
Autoscaling-Grenzen
Serverless-Compute skaliert elastisch, zusätzliche Kapazität steht aber nicht sofort ohne Wartezeit bereit. Bei stark schwankenden Lastspitzen entstehen sichtbare Hochlaufzeiten.
Offener GA-Termin
Bis Januar 2027 läuft ein Launch-Rabatt von dreißig Prozent. Wann Lakehouse//RT allgemein verfügbar wird und wie sich die Preise danach entwickeln, ist nicht öffentlich.
Fazit
Lakehouse//RT deckt die meisten Real-Time-Fälle auf Databricks selbst ab, für sehr viele gleichzeitige Nutzer bleibt Druid, Pinot oder ClickHouse die Vergleichsbasis.
Lakehouse//RT verändert die Real-Time-Architektur auf Databricks deutlich. Die alte Frage „Brauchen wir Druid oder ClickHouse neben dem Lakehouse?“ verschwindet nicht, sie wird zur Testfrage. Die meisten Anwendungsfälle im Sekunden- und Hundert-Millisekunden-Bereich lassen sich mit SQL Warehouses, Photon, Streaming Tables und Lakebase abdecken. Anwendungen mit einstelligen Millisekunden und sehr vielen gleichzeitigen Nutzern adressiert Lakehouse//RT ausdrücklich, die Belege stammen heute vor allem aus Databricks-Quellen. Die Beta ist auf Lese-Workloads beschränkt, ein GA-Termin liegt nicht vor.
Besonders relevant ist Lakehouse//RT für Unternehmen, die eine zweite Analyse-Engine bereits diskutieren oder gerade einführen. Wer heute Druid, Pinot oder ClickHouse plant, sollte den Lakehouse//RT-Beta-Test parallel laufen lassen. Wer Lakehouse//RT als Standardlösung setzen möchte, sollte für Profile mit sehr vielen gleichzeitigen Nutzern und Antwortzeiten im einstelligen Millisekundenbereich eine externe Engine als Vergleichsbasis behalten, solange unabhängige Benchmarks fehlen.
Typische Hinweise für die Lakehouse-RT-Klärung:
- Operative Dashboards werden im Sekundenbereich aktualisiert, niemand kann aber erklären, welcher technische Baustein für welche Antwortzeit verantwortlich ist
- Lakebase wird diskutiert, ohne dass ein konkreter operativer Anwendungsfall mit schnellen Schreib- oder Lesezugriffen definiert wurde
- Eine zusätzliche Analyse-Engine wird vorgeschlagen, weil ein einzelner Anwendungsfall sehr viele gleichzeitige Nutzer erwartet, während die übrigen Workloads im Sekundenbereich bleiben
- Lakehouse//RT wird auf Folien als Standard-Architektur gesetzt, ohne dass ein Lasttest gegen das eigene Anforderungsprofil gelaufen ist
Mein Vorschlag: Prüft Lakehouse//RT ernsthaft, sobald es um Antwortzeiten unter wenigen hundert Millisekunden geht, und behaltet Druid, Pinot oder ClickHouse als Vergleichsbasis, solange die Beta läuft. Für komplexere Fälle hilft ein Architecture Review, in dem das Anforderungsprofil gegen die Architektur-Optionen gerechnet wird.
Die Entscheidung hängt an gemessenen Antwortzeiten des konkreten Anwendungsfalls. Alles andere bleibt Produktdiskussion ohne belastbare Grundlage.
Klärt für jede Echtzeit-Anforderung zuerst die benötigte Antwortzeit und die erwartete gleichzeitige Nutzung, bevor ihr eine Engine auswählt.
Databricks BI & SQL Architecture Review
Ob eure Echtzeit-Anforderungen mit Databricks und Lakehouse//RT abgedeckt werden können oder ob eine zusätzliche Engine nötig ist, lässt sich in einem Databricks BI & SQL Architecture Review strukturiert bewerten.
- welche Anwendungsfälle direkt auf Databricks laufen können und welche wegen sehr niedriger Antwortzeiten oder sehr hoher Nutzerzahlen eine spezialisierte Engine benötigen
- wie ein Lakehouse//RT-Test gegen euer eigenes Lastprofil aussehen sollte
- welcher Architekturansatz zu Antwortzeiten, Nutzerzahlen und Datenmengen passt
FAQ
Lakehouse//RT ist eine Engine für sehr schnelle Abfragen von Databricks, die am 16. Juni 2026 als Beta angekündigt wurde. Sie arbeitet direkt auf Lakehouse-Tabellen in Delta und Iceberg, läuft unter Unity Catalog und verspricht Antwortzeiten im einstelligen bis zweistelligen Millisekundenbereich bei vielen gleichzeitigen Anfragen. Die zentrale Komponente ist eine neue Engine namens Reyden, ergänzt um AUTO-Sizing und inkrementelles Autoscaling. Die Beta ist auf Lese-Workloads beschränkt, ein GA-Termin ist nicht öffentlich.
