Databricks Lakehouse//RT verständlich erklärt

Databricks Real-Time Analytics bezeichnet den Verbund aus Event-Ingestion, Stream Processing, Delta-Tabellen und Abfragen mit niedriger Latenz, mit dem Unternehmen Daten Sekunden nach ihrer Entstehung auswerten. Lakehouse//RT ist darin die neue Serving-Schicht für Low-Latency-Abfragen: ein serverloses, read-only SQL Warehouse auf Basis der Reyden-Engine, das laut Databricks unter 100 Millisekunden bei 12.000 Abfragen pro Sekunde erreicht. Stand Oktober 2026 ist Lakehouse//RT Beta und ersetzt weder Streaming-Pipelines noch Lakebase.

Montag, 8 Uhr: 300 Außendienstmitarbeitende öffnen gleichzeitig dasselbe Echtzeit-Dashboard im Vertrieb, und die Ladezeit springt von zwei auf acht Sekunden. Bisher hieß die Standardantwort darauf: ein separates Serving-System neben dem Lakehouse, mit eigener Datenkopie, eigener Pipeline und eigenen Berechtigungen. Mit Lakehouse//RT bietet Databricks seit Juni 2026 eine Alternative direkt auf den vorhandenen Tabellen. Wir erklären, was Lakehouse//RT technisch ist, wie es sich von Lakebase und Databricks SQL unterscheidet und in welchen Fällen wir heute noch davon abraten.

Fangen wir mit dem Kern an.

Was ist Databricks Lakehouse//RT?

Lakehouse//RT (Lakehouse Real-Time) ist ein spezialisierter, serverloser SQL-Warehouse-Typ von Databricks für Low-Latency-Abfragen, also analytische Leseabfragen mit sehr niedriger Latenz und hoher Parallelität. Er beantwortet SELECT-Abfragen auf Delta-Lake- und Apache-Iceberg-Tabellen im Unity Catalog in Millisekunden bis wenigen hundert Millisekunden, ohne dass Daten in ein separates System kopiert werden.

Databricks hat Lakehouse//RT im Juni 2026 auf dem Data + AI Summit vorgestellt. Angetrieben wird es von Reyden, einer neuen Query-Engine, die speziell für operative Analysen, App Serving und Dashboards mit hunderten bis tausenden gleichzeitigen Nutzern gebaut wurde.

Das Problem, das Lakehouse//RT löst, kennen viele Teams aus eigener Erfahrung: Das Lakehouse ist die zentrale Datenbasis, aber für Abfragen im Millisekundenbereich reichte es bisher nicht. Also wurde ein spezialisiertes Serving-System danebengestellt, befüllt über CDC-Pipelines (Change Data Capture), mit eigener Rechteverwaltung. Lakehouse//RT soll diese zweite Welt überflüssig machen.

Lakehouse//RT vs. Real-Time Mode vs. Databricks Real-Time Analytics

Drei Begriffe, die sich ähnlich anhören und regelmäßig verwechselt werden:

• Lakehouse//RT beschleunigt Abfragen auf Tabellen, die bereits gespeichert sind. Es optimiert also die Query-Latenz.
• Real-Time Mode ist ein Ausführungsmodus von Spark Structured Streaming (Public Preview), der eintreffende Ereignisse kontinuierlich verarbeitet. Er optimiert die Processing-Latenz.
• Databricks Real-Time Analytics ist kein Produkt, sondern der Oberbegriff für die gesamte Kette aus Ingestion, Verarbeitung, Speicherung, Governance und Abfrage.

Der Unterschied ist mehr als Begriffsklauberei. Ein Dashboard kann in 50 Millisekunden antworten und trotzdem Daten zeigen, die zehn Minuten alt sind.

Warum Lakehouses die Datenarchitektur der Zukunft sind

In unserem Whitepaper erfahren Sie:

• Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
• Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
• Wie Sie Ihr internes Team befähigen, selbstständig KI Projekte zu implementieren.

Jetzt herunterladen

Wie funktioniert Lakehouse//RT innerhalb einer Real-Time-Analytics-Architektur?

Nehmen wir einen Maschinenbauer, der Sensordaten von 2.000 Anlagen als Real-Time Dashboard im Lakehouse für seinen Leitstand bereitstellen will. Die Frage „Wie schnell ist das?“ hat in dieser Architektur nicht eine Antwort, sondern fünf. Wir sprechen deshalb in Projekten konsequent vom Latenzbudget:

1. Ingestion-Latenz: Zeit von der Maschine bis zur Rohdaten-Tabelle (Bronze)
2. Processing-Latenz: Zeit für Validierung, Joins und Aggregationen
3. Freshness-Lag: Alter der Daten im Moment der Abfrage
4. Query-Latenz: Antwortzeit der Abfrage selbst
5. Action-Latenz: Zeit, bis ein Mensch oder System tatsächlich reagiert

Lakehouse//RT setzt ausschließlich bei Punkt 4 an. Wir erklären das Entscheidern gern mit einer Schnellkasse im Supermarkt: Sie verkürzt die Wartezeit beim Bezahlen enorm, füllt aber kein einziges Regal auf. Wenn die Ware im Lager feststeckt, hilft die schnellste Kasse nichts.

Reyden und das Skalierungsmodell

Lakehouse//RT läuft vollständig serverlos, Databricks betreibt die Infrastruktur. Interessant für Sie als Betreiber ist das Skalierungsmodell, denn es trennt zwei Dinge, die bei klassischen SQL Warehouses aneinander gekoppelt sind:

• Query Size (Small, Medium, Large, X-Large) legt fest, wie viel Rechenleistung eine einzelne Abfrage maximal bekommt, und bestimmt den Grundverbrauch.
• Autoscaling Maximum (in DBUs) begrenzt, wie weit das Warehouse für viele parallele Abfragen hochskaliert.
• Auto Stop fährt das Warehouse nach einer Leerlaufzeit herunter.

Anders als reguläres Serverless SQL skaliert Lakehouse//RT nicht in ganzen Clusterstufen, sondern fügt Rechenleistung inkrementell hinzu. Für Unternehmen bedeutet das: Sie können eine kleine Query Size mit hohem Concurrency-Limit kombinieren und zahlen nicht für große Einzelabfragen, wenn eigentlich nur viele kleine gleichzeitig laufen.

Warum es dafür eine eigene Engine braucht, zeigt der Blick auf das Lastverhalten. Klassische Analyse-Warehouses starten mit guten Antwortzeiten, stoßen aber ab einer bestimmten Parallelität an eine Wand, und die Latenz steigt sprunghaft. Spezialisierte Serving-Engines schaffen hohe Durchsätze bei einfachen Abfragen, geraten aber ins Straucheln, sobald Abfragen größer oder komplexer werden. Reyden ist darauf ausgelegt, beide Dimensionen zu erweitern: hohe Parallelität und ein breiter analytischer SQL-Umfang inklusive Joins.

Was Unternehmen mit Lakehouse//RT konkret gewinnen

Echtzeit-Dashboards bleiben reaktionsfähig, auch wenn hunderte Nutzer gleichzeitig zugreifen

Laut Databricks (2026) erreicht Lakehouse//RT auf Standard-Analytics-Benchmarks unter 100 Millisekunden Latenz bei 12.000 Abfragen pro Sekunde. Das ist allerdings eine Herstellerangabe aus der Beta, kein Produktions-SLA. Die Richtung ist trotzdem klar: Lastspitzen wie der Montagmorgen im Vertrieb oder der Schichtwechsel im Werk verlieren ihren Schrecken.

Auch aus der Praxis gibt es erste Belege. Meta nutzt Lakehouse//RT für unternehmensweite Analysen in Bereichen wie Supply Chain und Finance, wo Analysten auch bei hoher Last und auf sehr großen Tabellen sofortige Antworten erwarten. Typische Abfragen liefern dort Ergebnisse im Bereich von zehn Millisekunden, direkt auf den Lakehouse-Daten und ohne separates System daneben. Ein anderer Kunde, der zuvor einen eigenen Serving-Stack betrieb, erreichte nach dem Wechsel laut Databricks eine bis zu 16-fach bessere Performance über seine Abfragen hinweg.

Ein separates Serving-System samt Kopierpipelines entfällt

Wer heute eine spezialisierte Echtzeitdatenbank neben dem Lakehouse betreibt, pflegt eine zweite Datenhaltung mit eigener Synchronisation. Jede dieser Pipelines kann ausfallen, verzögern oder inkonsistente Stände erzeugen. Lakehouse//RT liest direkt die Gold-Tabellen, die Ihre Data Engineers ohnehin bauen. Ein Real-Time Dashboard im Lakehouse greift damit auf dieselbe Datenbasis zu wie Ihr Standard-Reporting.

Berechtigungen und Lineage bleiben an einer Stelle

Governance, Berechtigungen und Business-Logik bleiben im Unity Catalog. Für IT-Leiter heißt das: kein zweites Rechtekonzept, das bei jedem neuen Mitarbeitenden separat gepflegt werden muss. Eine wichtige Einschränkung dazu folgt weiter unten, denn feingranulare Regeln wie Row-Level Security greifen in der Beta noch nicht.

Kosten für Einzelabfrage und Gleichzeitigkeit getrennt steuern

Durch die Trennung von Query Size und Autoscaling-Maximum dimensionieren Sie nach Ihrem tatsächlichen Lastprofil. Ein Kundenportal mit vielen kleinen Abfragen braucht etwas anderes als ein Analystenteam mit wenigen komplexen Joins, und genau das lässt sich jetzt abbilden.

KI-Agenten und Apps nutzen dieselben Daten wie das BI

Databricks positioniert Lakehouse//RT ausdrücklich auch für KI-Agenten, die in hoher Frequenz Abfragen stellen. Das ist der Punkt, den wir für mittelfristig am relevantesten halten: Agenten erzeugen eine Abfragelast, für die klassische BI-Warehouses nie ausgelegt waren.

Expertentipp von Laurenz, CTO bei Datasolut:

Der unterschätzte Vorteil ist nicht die Geschwindigkeit, sondern die wegfallende zweite Datenhaltung. Jede Kopie in einem separaten Serving-System bringt eine eigene Pipeline, eigene Berechtigungen und eigene Fehlerquellen mit, und genau dort entstehen im Betrieb die meisten Tickets.

Real-Time Analytics auf Databricks planen? Wir prüfen Ihre Architektur.

Ob Lakehouse//RT, Databricks SQL oder ein klassisches Streaming-Setup: Die richtige Wahl hängt an Ihrem Latenzbudget, nicht am neuesten Feature. Wir bewerten Ihre bestehende Architektur und zeigen, an welcher Stelle der Kette sich Investitionen tatsächlich auszahlen.

Lakehouse//RT, Lakebase oder Databricks SQL: Was passt wann?

Seit dem Summit im Juni beantworten wir in Erstgesprächen regelmäßig dieselbe Frage: „Brauchen wir jetzt Lakebase oder Lakehouse//RT?“ Die kurze Antwort: Die beiden konkurrieren nicht. Lakebase ist eine Transaktionsdatenbank, Lakehouse//RT eine Analyse-Engine.

Unser Urteil ist eindeutig, und zwar nach Zugriffsmuster:

• Lakehouse//RT, wenn viele Nutzer, Apps oder Agenten dieselben Lakehouse-Daten analytisch und read-only abfragen und Antwortzeiten unter einer Sekunde geschäftlich zählen.
• Lakebase, wenn Ihre Anwendung Daten schreibt, Transaktionen braucht, einzelne Datensätze nachschlägt oder Session- und Agenten-State hält.
• Databricks SQL, wenn Sie ETL, Writes, Jobs, Genie oder Federation brauchen, oder wenn Antwortzeiten von ein bis drei Sekunden völlig ausreichen. Das ist im Mittelstand der häufigste Fall.

Die Workload-Form entscheidet

Eine hilfreiche Faustregel ordnet Workloads nach Dauer und Breite. Je kürzer und gezielter die Abfrage, desto eher gehört sie auf Lakehouse//RT.

Databricks selbst formuliert es deutlich: Lakehouse//RT ist keine universell schnelle Query-Engine, sondern eine fokussierte Serving-Engine. Genau dieser Fokus erklärt, warum sie innerhalb ihrer Spur so gut abschneidet.

Für wen lohnt sich Lakehouse//RT, und wann nicht?

Lakehouse//RT lohnt sich besonders, wenn:

• Ihr Unternehmen operative Echtzeit-Dashboards betreibt, auf die zu bestimmten Zeiten hunderte Nutzer gleichzeitig zugreifen, etwa Schichtübersichten in der Produktion oder Tourenstatus in der Logistik
• Sie Kunden oder Lieferanten über ein Portal Kennzahlen bereitstellen und die Antwortzeit Teil des Produkterlebnisses ist
• Sie heute einen separaten Serving-Layer neben Databricks betreiben, den Sie gern abschalten würden
• KI-Agenten in Ihrer Planung eine wachsende Rolle spielen und viele kleine Abfragen gegen dieselben Tabellen stellen werden
• Sie Telemetrie, Clickstream oder Logs fortlaufend auswerten und Anwendungen auf Basis dieser Daten Entscheidungen treffen

Lakehouse//RT ist (noch) nicht die richtige Wahl, wenn:

• Ihre Fachbereiche täglich oder wöchentlich entscheiden und ein Dashboard mit drei Sekunden Ladezeit niemanden aufhält
• Sie Row-Level Security, Column Masking oder Attributbasierte Zugriffskontrolle (ABAC) zwingend benötigen
• Ihre Sicherheitsarchitektur Outbound Private Link oder ein Compliance Security Profile voraussetzt
• Ihr eigentliches Problem langsame Pipelines sind und nicht langsame Abfragen
• Ihre Abfragen ganze Tabellen lesen (Full-Table-Scans) oder dutzende bis hunderte Gigabyte verarbeiten müssen
• Ihre Abfragen heute auf Databricks SQL Minuten statt Sekunden laufen

Wie ist der aktuelle Stand von Lakehouse//RT im Oktober 2026?

Dieser Abschnitt ist bewusst ausführlich, denn hier entscheidet sich, ob Lakehouse//RT für Sie schon heute in Frage kommt. Die Plattform entwickelt sich gerade sehr dynamisch, daher zuerst der Status aller relevanten Bausteine:

Was in der Beta noch fehlt

• Schreibzugriffe: Nur SELECT, kein INSERT, MERGE, DDL, GRANT oder OPTIMIZE
• Feingranulare Zugriffskontrolle: Kein ABAC, keine Row-Level Security, kein Column Masking
• Netzwerk und Compliance: Kein Outbound Private Link, keine Serverless Egress Control, keine Compliance Security Profiles
• Tabellen und Dienste: Keine External Tables, keine System Tables, kein Delta Sharing, keine Foreign Tables, kein Hive Metastore, keine Unterstützung für Genie und Jobs-Tasks. Abfragen auf Tabellen mit ABAC-Richtlinien schlagen fehl
• Funktionen: Keine Python UDFs, keine AI Functions, keine Geo- und XML-Funktionen
• Konnektivität: Verbindungen nur über die Statement Execution API (SEA). Treiber für Python, Node.js, JDBC, ADBC und Go müssen diesen Pfad explizit aktivieren, ODBC ist noch in Arbeit, das ältere Thrift-Protokoll wird nicht unterstützt

Machen wir uns nichts vor: Die Punkte zu Zugriffskontrolle und Netzwerk sind für viele Unternehmen im DACH-Raum keine Details, sondern K.-o.-Kriterien. Wer personenbezogene Daten über Row-Level Security schützt oder Private Connectivity zur Pflicht gemacht hat, kann Lakehouse//RT heute nur für unkritische Daten testen.

Best Practices für die Lakehouse Einführung

• Formulieren Sie die Anforderung so, dass man sie messen kann: „95 Prozent der Abfragen im Echtzeit-Dashboard unter 300 Millisekunden bei 200 gleichzeitigen Nutzern“ statt „das Dashboard soll in Echtzeit laden“.
• Prüfen Sie im selben Schritt, welche Stufe des Latenzbudgets heute tatsächlich bremst, und gleichen Sie die Beta-Einschränkungen mit Ihren Security-Vorgaben ab.
• Managed Tables sind Pflicht. Lakehouse//RT arbeitet nur mit Unity-Catalog-Managed-Tables. Der Grund: Weil alle Lese- und Schreibzugriffe über den Katalog laufen, kann die Engine Transaktionsinformationen zwischenspeichern. Bei External Tables müsste sie bei jedem Lesevorgang mehrere Cloud-Storage-Aufrufe absetzen, was laut Databricks im Einzelfall fast 100 Millisekunden kostet.

• Liquid Clustering aktivieren. Ohne gutes Clustering kann die Engine keine Daten überspringen. Wenn Sie die passenden Schlüssel nicht kennen, nutzen Sie CLUSTER BY AUTO. Stammt die Tabelle aus einem System mit bewährten Sortierschlüsseln, clustern Sie nach diesen Spalten.
• Metric Views mit Metric Materialization für BI. BI-Workloads scannen und aggregieren oft große Datenmengen, und daran ändert keine Engine etwas. Wenn Sie Kennzahlen jedoch als Metric Views im Unity Catalog definieren, berechnet Databricks häufig genutzte Aggregationen im Hintergrund vor und hält sie inkrementell aktuell. Lakehouse//RT wählt bei der Abfrage dynamisch die passende Materialisierung.

Fazit

Lakehouse//RT schließt eine Lücke, die Databricks-Nutzer lange mit Zusatzsystemen überbrückt haben: Abfragen im Millisekundenbereich direkt auf gouvernierten Lakehouse-Tabellen. Der richtige Zeitpunkt für Lakehouse//RT ist jetzt, wenn Sie bereits ein konkretes Concurrency-Problem haben und es im PoC unter Ihren Bedingungen testen wollen. Für alle anderen gilt: erst das Latenzbudget klären, dann die Engine wählen.

Vinzent Wuttke

Geschäftsführer

Ihr nächster Schritt mit uns!

Databricks ist eine der leistungsfähigsten Plattformen für Daten und KI – aber ihr volles Potenzial entfaltet sich erst, wenn Ihr Team sie wirklich beherrscht. Lassen Sie uns gemeinsam schauen, welche Schulungspakete zu Ihrer Ausgangssituation passen.

Im kostenlosen Erstgespräch klären wir:

• Welche Rollen und Teams von welchem Paket am meisten profitieren
• Ob und wie wir Inhalte auf Ihre Datenarchitektur und Use Cases anpassen
• Wie ein realistischer Zeitplan und die nächsten Schritte aussehen

Erstgespräch vereinbaren

FAQ – Die wichtigsten Fragen beantwortet