Stell dir vor, du bist Detektiv, aber du darfst nur in einem Raum ermitteln. Du siehst Akten aus diesem Raum, hörst Zeugen aus diesem Raum – und ziehst deine Schlüsse. Was du nicht siehst: die Beweise im Nebenzimmer, die Protokolle im Keller, die Aussagen aus dem Nachbargebäude. Dein Urteil klingt trotzdem souverän, weil es auf dem basiert, was du hast. Nur: Es ist unvollständig. Genau das passiert, wenn wir KI-Agenten auf eine Datenplattform setzen, die nicht alle Quellen erreicht.
Vergangene Woche wurde bekannt, dass SAP Dremio übernimmt. Auf den ersten Blick wirkt das wie eine weitere Konsolidierung im Data-Engine-Markt. Genauer betrachtet zeigt sich: Die Ära der reinen Lakehouse-Engines ist mit dem Aufkommen von KI-Agenten vorbei. Wer nur im eigenen See fischt, wird für die neuen Workloads irrelevant.
Der Lakehouse-Kompromiss – und warum er für Analytics funktionierte
Um zu verstehen, was hier geschieht, müssen wir kurz ausholen. Ein Lakehouse ist im Kern ein Data Warehouse, das auf einem Data Lake aufsetzt. Die Idee: Statt Daten in teure, proprietäre Speicher zu kopieren, liegen sie in offenen Formaten wie Parquet auf einem Objektspeicher wie S3 oder ADLS. Eine Engine wie Dremio oder Trino (Presto) kann darauf direkt lesend zugreifen, optimiert durch Caching, Precomputing und intelligente Abfrageplanung. Für klassische Business Intelligence – Dashboards, Reports, feste Kennzahlen – war das ein Segen. Du materialisierst die häufigsten Abfragen als sogenannte „Reflections“ oder „Materialized Views“, planst nachts einen Refresh, und am Morgen läuft alles blitzschnell. Der Trade-off war klar: Du bringst die Daten in den See, baust dort dein Modell, und die Engine liefert Performance für die vorhersehbaren Fragen.
Dieses Modell hatte in den vergangenen Jahren enorme Erfolge. Viele Unternehmen haben ihre Data Warehouses abgelöst oder ergänzt. Die Kostenvorteile und die Flexibilität der offenen Formate waren überzeugend. Und für den Menschen, der einmal am Tag ein Dashboard öffnet, war die Latenz von Sekunden völlig ausreichend. Das Problem: KI-Agenten ticken fundamental anders.
Wie KI-Agenten das Modell zerbrechen
Ein KI-Agent ist kein menschlicher Analyst, der sich einen Kaffee holt, während ein Report rendert. Ein Agent ist eine automatisierte Einheit, die in Echtzeit Entscheidungen trifft – und dafür benötigt sie Zugriff auf das gesamte Datenökosystem, nicht nur auf einen vorbereiteten Ausschnitt. Der Artikel, den wir hier analysieren, macht einen entscheidenden Punkt: Die Reichweite einer Engine (Reach) ist keine Performance-Kennzahl mehr, sondern eine Vertrauenskennzahl.
Stell dir vor, ein Agent soll das Kündigungsrisiko eines Kunden bewerten. Er hat Zugriff auf das CRM, aber nicht auf das Ticketsystem. Er sieht: Der Kunde hat seit drei Monaten nichts gekauft. Er schlussfolgert: hohes Risiko. Was er nicht sieht: Der Kunde hat gestern einen Premium-Support-Fall eröffnet, der auf eine bevorstehende Verlängerung hindeutet. Der Agent liefert eine Antwort – aber sie ist nicht nur unvollständig, sie ist zuversichtlich falsch. Und anders als ein Mensch hat der Agent kein Bauchgefühl, das ihm sagt: „Moment, hier fehlt was.“ Er gibt die Antwort mit derselben Sicherheit, als hätte er alle Systeme abgefragt. Das ist ein gefährlicherer Fehlermodus als jede Latenz. Latenz sagt dir: Irgendwo hakt es. Eine zuversichtliche Fehlantwort tut das nicht.
Hinzu kommt ein zweites, subtileres Problem: die Unvorhersagbarkeit von Agenten-Workloads. Ein Dashboard fragt immer dieselben Dinge ab: „Umsatz letzte Woche“, „Top 10 Produkte“. Du kannst diese Abfragen vorberechnen. Ein Agent dagegen generiert seine Abfragen dynamisch. Er startet mit einer Frage, bekommt eine Antwort, und leitet daraus die nächste Frage ab – die du nie vorhergesehen hast. Du kannst keine Materialized Views bauen für Fragen, die erst fünf Sekunden vor Ausführung entstehen. Eine Engine, die auf Precomputing angewiesen ist, wird mit einem Agenten, der zur Laufzeit neue Pfade erkundet, strukturell nie mithalten können, egal wie gut sie optimiert ist.
Was KI wirklich von einer Datenplattform fordert
Aus diesen Beobachtungen leitet der Autor eine klare Anforderungsliste ab, die nichts mit Markennamen zu tun hat, sondern mit Architekturentscheidungen. Lass uns diese Anforderungen durchgehen, denn sie sind der Maßstab, an dem sich jede Plattform messen lassen muss.
Erstens: Reichweite muss nahezu vollständig sein. Nicht „die meisten unserer Daten“, sondern alle relevanten Quellen – relationale Datenbanken, Data Warehouses, Objektspeicher, SaaS-Systeme. Ein System, das ein Agent nicht erreicht, ist nicht etwa eine Lücke, die er umsichtig umgeht. Es ist eine stille Wissenslücke, die weder du noch der Agent bemerken, bis die falsche Entscheidung getroffen ist.
Zweitens: Parallelität muss skalieren, als wären tausend Analysten gleichzeitig am Werk. Ein Mensch öffnet ein Dashboard. Ein Agentenfleet feuert Dutzende parallele Abfragen ab – und die Plattform muss unter dieser Last genauso schnell sein wie im Leerlauf. Eine Engine, die für einen Benutzer schnell ist, aber unter realer Last einbricht, wird genau dann langsamer, wenn es am kritischsten ist.
Drittens: Kontext muss begrenzt und relevant sein. Ein Agent bekommt nicht das gesamte Schema einer Datenbank oder einen ganzen Dokumenten-Pool – das würde seinen Kontext aufblähen mit Rauschen und zu Fehlschlüssen führen. Stattdessen braucht er den spezifischen Ausschnitt: die richtigen Tabellen, die richtigen Spalten, die passenden Business-Definitionen, zugeschnitten auf die aktuelle Frage.
Viertens: Aktualität muss strukturell sein, nicht geplant. Die Frage eines Agenten entsteht 90 Sekunden vor der Antwort. Er braucht Daten von diesem Moment, nicht vom letzten nächtlichen Refresh. Die Frage „Wie aktuell darf es sein?“ war früher eine Business-Entscheidung. Für viele agentische Anwendungen liegt die Antwort heute bei null Sekunden.
Fünftens: Governance muss mit den Daten reisen, nicht daneben sitzen. Wenn zwei Agenten auf unterschiedliche Systeme zugreifen, die unterschiedliche Geschäftslogik anwenden, und sie kommen zu widersprüchlichen Ergebnissen – dann ist das nicht nur eine kleine Inkonsistenz. Es untergräbt das Vertrauen in den gesamten KI-Ansatz. Governance muss zur Abfragezeit durchgesetzt werden, nicht nachträglich.
Was das für die Branche bedeutet
Keine dieser Anforderungen ist neu, aber zusammen ergeben sie ein Profil, das reine Lakehouse-Engines strukturell nicht erfüllen können. Dremio ist kein Einzelfall – es steht exemplarisch für eine ganze Kategorie von Anbietern, die auf „Bring your data to the lake“ gesetzt haben. Der Verkauf an SAP ist der deutlichste Hinweis darauf, dass dieser Ansatz an seine Grenzen stößt.
Der Autor des zugrundeliegenden Artikels argumentiert, dass die Lösung in einer föderierten Architektur liegt: Daten dort lassen, wo sie sind, und über eine Engine abfragen, die alle Quellen gleichzeitig erreicht, ohne sie vorher zu bewegen. Das ist die Design-Philosophie hinter Starburst (dem Unternehmen, für das der Autor arbeitet) – aber es ist auch eine logische Schlussfolgerung aus den Anforderungen, die KI mitbringt. Ob man Starburst mag oder nicht: Die Fragen, die im Raum stehen, sind systemunabhängig. Kann meine Plattform alles erreichen, was meine Agenten brauchen? Hält sie unter der Last stand, die Agenten erzeugen? Kann sie Fragen beantworten, die vor fünf Sekunden noch nicht existierten?
Wenn ein Anbieter auf diese Fragen mit „arbeiten wir dran“ antwortet, ist das ehrlich. Aber dann solltest du sicherstellen, dass du die Fragen stellst, bevor du dich bindest – nicht hinterher, wenn der Agent bereits falsche Entscheidungen trifft.
Dremios Verkauf ist ein Datenpunkt. Er ist nicht die Geschichte selbst, sondern der Moment, in dem eine Verschiebung für einen Anbieter sichtbar wurde. Die Verschiebung ist größer und wird nicht mit einer Übernahme enden. Wer KI ernsthaft einsetzen will, muss Datenplattformen so bauen, dass sie dem Denken von Agenten folgen – nicht umgekehrt. Das ist kein Feature-Wettbewerb mehr. Es ist die neue Grundlage für Vertrauen in automatisierte Entscheidungen.
Quelle: starburst.io
