Zum Inhalt springen 
„KI hat kein Intelligenzproblem. Sie hat ein Kontextproblem.“ So fasste Ali Ghodsi die Lage beim Databricks Data + AI Summit 2026 zusammen – und traf damit etwas, das die meisten Berichte übersehen haben. Das eigentliche Signal war keine neue Welle von Agenten-Demos. Es war eine stillere, strukturelle Verschiebung: Software, nicht Menschen, wird zum primären Konsumenten von Unternehmensdaten. Lakebase, die operative Datenbank von Databricks, bewältigt bereits 12 Millionen Datenbankstarts pro Tag. Wenn Agenten in diesem Ausmaß Daten erzeugen und abfragen, beginnt die Architektur, auf der die meisten Unternehmen noch laufen – Daten überall hin kopieren und mit ETL und CDC zusammenflicken – unter ihrem eigenen Gewicht zu kollabieren. Zwei Ankündigungen adressieren das tatsächlich. Der Rest war Lärm.
Was sich wirklich geändert hat – und was Lärm war
Der Summit war groß: mehr als 30.000 Teilnehmer, 800+ Sessions und eine Flut von KI-Tool-Ankündigungen (Genie Ontology, Genie One, eine lange Liste von Agenten-Features). Das meiste davon ist früh und hype-lastig. Wer eine Datenplattform in der Produktion betreibt, sollte nicht auf die Demos schauen. Die relevanten Änderungen betreffen das Fundament: Lakehouse//RT und LTAP. Beide sind bemerkenswert für das, was sie entfernen – nicht für das, was sie hinzufügen. Sie nehmen Infrastruktur aus der Architektur heraus. Das ist der rote Faden, und das Gegenteil davon, wie die meisten Anbieter etwas Neues verkaufen.
Lakehouse//RT: Echtzeit ohne ein zweites System
Heute bedeutet die Bereitstellung von Echtzeit-Workloads (Live-Dashboards, kundenseitige Apps, Agenten-Retrieval) in der Regel, einen separaten Serving-Layer an das Lakehouse anzudocken: ClickHouse, Pinot, Druid oder Redis. Jedes davon ist eine weitere Kopie der Daten, eine weitere Sync-Pipeline, die aktuell gehalten werden muss, und ein weiteres Governance-Modell.
Lakehouse//RT entfernt diesen Layer. Angetrieben von einer neuen Engine namens Reyden, führt es Abfragen mit niedriger Latenz direkt auf dem Lakehouse aus: rund 10 Millisekunden bei kleineren Datensätzen, unter 100 Millisekunden bei größeren, bis zu 16x schneller als separate Serving-Layer – bei gleichzeitiger Unterstützung von Zehntausenden gleichzeitiger Nutzer und Agenten. Jede Abfrage läuft nativ innerhalb der Unity Catalog-Governance. Kein proprietäres Format, keine CDC-Pipeline, keine zweite Berechtigungsebene zum Abgleichen. Es ist heute in der Beta-Phase, also sollte man es als klare Richtung behandeln, nicht als produktionsreifen Austausch. Aber die Richtung ist eindeutig: Der Serving-Tier kollabiert ins Lakehouse.
LTAP: Das Ende der OLTP/OLAP-Trennung
Die zweite Ankündigung greift eine 40 Jahre alte Annahme an. Jahrzehntelang betrieben Unternehmen eine Datenbank für Transaktionen (OLTP) und eine separate für Analysen (OLAP), mit ETL oder CDC, das Daten zwischen beiden transportiert.
LTAP, kurz für Lake Transactional/Analytical Processing, legt beides auf eine einzige verwaltete Kopie. Es kombiniert Lakebase (serverloses Postgres) mit dem Lakehouse, sodass Transaktionsdaten direkt in Delta oder Iceberg landen – dieselbe Kopie, die analytische Workloads bereits lesen. Das ist kein klassisches HTAP, bei dem eine Engine alles versucht und nichts gut macht. Databricks behält spezialisierte Engines, vereinheitlicht aber den Storage und die Governance darunter: eine einzige Quelle der Wahrheit, keine Replikate, keine Pipelines. Warum jetzt? Wieder: Agenten. Wenn der Hauptnutzer der Datenplattform Software ist, die täglich Millionen von Datenbanken hochfährt, skaliert eine Architektur aus dutzenden veralteten Kopien nicht. LTAP kommt bald als Teil von Lakebase.
Was das für Retail und Banking bedeutet
Für Retail geht es darum, in Echtzeit zu operieren, ohne die Integrationssteuer zu zahlen. Echtzeit-Bestandsübersicht über alle Kanäle, Personalisierung, die mit einem Agenten Schritt hält statt mit einem nächtlichen Batch, und Tausende gleichzeitiger Sessions ohne separaten Echtzeit-Tier. Weniger Infrastruktur bedeutet niedrigere Kosten und einen schnelleren Weg von der Idee zur Live-Anwendung.
Für Banking liegt der größere Gewinn in der Governance. Echtzeit-Entscheidungsfindung zählt, aber der strukturelle Vorteil ist, dass weniger Datenkopien eine kleinere Angriffs- und Prüffläche sowie sauberere Lineage für Regulatoren bedeuten. Eine Unity Catalog-Geschichte ist weit einfacher zu verteidigen als eine Abstimmungsübung zwischen einer Transaktionsdatenbank, einem Warehouse und drei Serving-Layern. Das neue Cross-Region Disaster Recovery in Lakebase gewinnt an Bedeutung, wenn Agenten Operationen übernehmen, die nicht ausfallen dürfen.
Der gemeinsame Nenner: Die Kosten für KI-Nativität sinken deutlich, wenn man parallele Architekturen nicht mehr warten muss. Genau das ist das Problem, an dem wir arbeiten.
Ehrliche Einschätzung: Richtung gesetzt, aber noch nicht fertig
Eine Anmerkung, die klar ausgesprochen werden muss: Lakehouse//RT ist in der Beta und LTAP kommt demnächst. Niemand sollte seinen laufenden Stack dieses Quartal auf Basis einer Keynote auseinandernehmen. Aber die Plattformrichtung ist jetzt gesetzt – und das ist die Grundlage für die Planung. Der strategische Schritt ist, aufzuhören, neues Legacy zu bauen. Wenn der nächste Echtzeit-Use-Case oder der nächste operative Datensatz ansteht, sollte man ihn für dieses einheitliche Modell entwerfen, statt einen weiteren Serving-Layer oder eine weitere Sync-Pipeline hinzuzufügen, die man in zwei Jahren wieder abbauen muss. Die Teams, die den nächsten Zyklus gewinnen, sind bereits KI-nativ in ihrer Architektur – nicht nur in ihren Pilotprojekten.
Wo mindit.io ansetzt
Die meisten Unternehmen experimentieren mit KI. Wir machen sie KI-nativ. Als Databricks-Partner, gemeinsam mit Microsoft, übersetzt mindit.io Plattformverschiebungen wie LTAP und Lakehouse//RT in konkrete Architekturentscheidungen für Retail und Banking: was jetzt gebaut werden sollte, worauf man warten kann und wie man Komplexität vermeidet, die man später bereut. Wer eine klare Einschätzung des eigenen Stacks möchte, kann ein 60-minütiges Architecture Review mit unserem Team buchen. Wir kartieren die aktuelle Datenarchitektur gegen LTAP und Lakehouse//RT und zeigen konkret, wo Kopien, Pipelines und Serving-Layer herausfallen.
—
mindit.io ist ein KI-nativer Transformationspartner und zertifizierter Databricks-Partner. Kontakt: sales@mindit.io
