Einige Notizen vom Databricks Data + AI Summit 2026: Warum die Datenschicht wieder wichtig ist
Nach dem diesjährigen Databricks Data + AI Summit habe ich weniger über eine einzelne Ankündigung nachgedacht als vielmehr über eine Frage, die mich schon seit einer Weile beschäftigt:
Wenn AI wirklich in die Produktion übergeht, was wird dann aus der Datenschicht?
Meine aktuelle Antwort ist einfach, auch wenn die Implikationen es nicht sind: In diesem Zyklus ist die Datenschicht der Teil des AI-Stacks, der am langsamsten neu bewertet wurde. Das beginnt sich zu ändern.
Daten: der Teil des AI-Stacks, den der Markt noch nicht eingepreist hat
Algorithmen wurden öffentlich neu bewertet. Modelle verbessern sich schnell, und die Branche kann den Fortschritt fast jede Woche sehen. Compute wurde von NVIDIA, den Cloud-Anbietern und den Kapitalmärkten neu bewertet. Jeder versteht, dass GPUs wichtig sind.
Daten haben sich langsamer bewegt. Nicht, weil sie weniger wichtig wären. Das Gegenteil ist der Fall. Daten werden langsam neu bewertet, weil es schwierig ist, über sie zu sprechen, und noch schwieriger, sie in Ordnung zu bringen. Unternehmensdaten sind chaotisch, verstreut, dupliziert, veraltet und voller Berechtigungen, die niemand vollständig versteht. Geschäftliche Semantiken passen systemübergreifend nicht sauber zusammen. Das, was Menschen „Echtzeit“ nennen, ist oft immer noch ein geplanter Job, der irgendwann letzte Nacht gelaufen ist.
Diese Arbeit ist schmerzhaft. Sie ist auch nicht besonders glamourös. Aber sobald AI von Demos in die Produktion übergeht, lässt sich der Schmerz nicht mehr verbergen.
In Gesprächen mit Menschen, die Modelle bauen und trainieren, darunter auch bei OpenAI und Anthropic, kommt die Diskussion oft auf denselben Punkt zurück. Modelle konvergieren. Compute kann gekauft werden, zumindest wenn man genug Geld hat. Die verteidigungsfähige Schicht wird zunehmend zu den Daten: ihrer Qualität, ihrer Aktualität, den Berechtigungen rund um sie und der Geschwindigkeit, mit der sie in nützlichen Kontext verwandelt werden können.
Das ist nicht nur ein Problem der Anwendungsschicht. Innerhalb von Modellunternehmen hängt die Modellqualität weiterhin stark von der Datenpipeline ab. Ein Trainingslauf kann Tage der Vorbereitung erfordern, bevor das erste ernsthafte Experiment beginnt. Wenn ein vorgelagertes Feld fehlerhaft ist, ein Batch falsch gelabelt ist oder eine Filterregel falsch ist, können Tage an Compute und Wartezeit verschwinden, bevor überhaupt jemand bemerkt, dass die Verlustkurve abgedriftet ist.
AI-Agenten machen das Datenproblem unmöglich zu verbergen
Agenten legen dasselbe Problem in einer operativeren Form offen.
Wenn AI-Agenten in der Produktion scheitern, liegt die erste Ursache oft nicht darin, dass das Modell unfähig ist. Es liegt daran, dass das Modell auf dem falschen Kontext handelt: ein Datensatz, auf den es nicht zugreifen kann, ein Dokument, das vor sechs Stunden abgelaufen ist, eine Datenquelle, die sich über Nacht still verändert hat, oder ein Retrieval-Pfad, der zu teuer ist, um oft genug genutzt zu werden. Kürzlich habe ich gesehen, wie ein starkes Team fast eine Woche durch eine veraltete Kontext-Pipeline verlor. Der Agent beantwortete selbstbewusst die Frage von gestern. Das Modell war nicht dumm. Der Kontext war falsch, und das System hatte keinen sauberen Weg nachzuweisen, wo der Fehler in die Schleife gelangt war.
Das ist der Fehlermodus, der zählt. Der nächste Infrastruktur-Engpass ist nicht einfach besseres Reasoning. Es ist frischer, vertrauenswürdiger, günstiger und auditierbarer Kontext in dem Moment, in dem ein Modell oder Agent eine Entscheidung trifft.
Deshalb glaube ich, dass die Datenschicht der nächste Teil des AI-Stacks ist, der neu bewertet wird.
Databricks zielt auf das richtige Problem
Ich bin skeptisch gegenüber vielen Produkten, die sich „AI data platforms“ nennen. Zu oft kommt die Geschichte vor dem System.
Databricks ist anders genug, dass ich denke, es verdient ernsthafte Aufmerksamkeit. Zwei Dinge sind mir beim Summit aufgefallen.
Das erste ist immer noch die Engineering-Kultur. Bei der Größe von Databricks wäre es leicht, dass das Unternehmen rein vertriebsgetrieben wird. Doch die Gründer stehen weiterhin auf der Bühne und sprechen über Execution Engines, Transaktionen, Echtzeitanalysen und die Rohre unter dem Produkt. Das respektiere ich. Man spürt, wenn ein Unternehmen Produkt- und Engineering-Intuition weiterhin im Kern trägt. Das zeigt sich in kleinen Architekturentscheidungen lange bevor es in einer Keynote sichtbar wird.
Das zweite ist die Kundenbasis. Die Nutzer, mit denen ich auf dem Summit gesprochen habe, sprachen nicht über KI als Demo-Ebene. Sie versuchten, KI in Produktionssysteme zu bringen, und die Probleme, die sie beschrieben, waren viel konkreter: Agenten müssen Geschäftsstatus lesen und schreiben; Echtzeitanalysen können sich die Kosten des Verschiebens von Daten nicht weiter leisten; Pipelines müssen autonomer werden; das Verhalten von Agenten braucht Governance zur Laufzeit, nicht erst im Nachhinein.
Deshalb sind Ankündigungen wie Lakebase, Lakehouse//RT, Datenagenten und KI-Governance wichtig. Die Namen sind weniger wichtig als die Richtung. Transaktionen näher an den Lake bringen. Echtzeitanalysen zurück zur selben Datengrundlage führen. Mehr von der Pipeline automatisieren. Governance von „wer darf diesen Datensatz sehen“ auf „was darf dieser Agent in diesem konkreten Schritt tun?“ erweitern.
Ich sehe das nicht als falsche Abzweigung. Ich sehe es als Beleg dafür, dass viele von uns aus unterschiedlichen Blickwinkeln auf dieselbe Zukunft schauen.
Die Datenbank expandiert. Sie ist nicht länger nur ein Ort zum Speichern und Abfragen von Daten. Sie wird zur Grundlage für Fakten, Zustand, Semantik, Governance und Handlung.
Die Karte ist gut. Aber sie ist nicht fertig.
Databricks liegt mit der Richtung richtig. Das bedeutet nicht, dass die Architektur ihre endgültige Form erreicht hat.
Foto: The Known Data Realm · Databricks Data + AI Summit 2026
Ich sehe drei Bereiche, in denen die Karte noch unvollständig ist.
Die Lakebase selbst.
Mit Postgres zu beginnen, ist ein kluger Einstiegspunkt. Entwickler kennen es. Das Ökosystem ist riesig. Kompatibilität senkt die Hürden bei der Einführung. Das ist wichtig.
Aber die Architektur, die Menschen durch die Tür bringt, ist nicht immer die Architektur, die den finalen Workload gewinnt.
Operative Systeme im KI-Zeitalter brauchen Transaktionen, Speicher, Vektoren, multimodale Daten, Traces, Branching, Rollback und eine sehr fein granulare Mandantenisolierung. Ein traditioneller relationaler Kern kann einiges davon über Erweiterungen und umgebende Dienste bereitstellen, aber dadurch wird es nicht nativ. Klassisches Postgres wurde weder für cloud-native verteilte Skalierung noch für Agenten entworfen, die kurzlebige Datenbanken erstellen, Zustand forken, in Speicher schreiben, Traces erzeugen und wieder verschwinden.
Postgres näher an Objektspeicher zu rücken, lässt diese Fragen nicht verschwinden. Objektspeicher ist günstig und zuverlässig, aber standardmäßig nicht latenzarm. Damit er sich schnell anfühlt, braucht man eine Cache-Ebene, die zugleich aggressiv und korrekt ist. Ein Cache, der unter echter transaktionaler Last stabil bleibt, ist eines der schwierigsten Systemprobleme in Datenbanken. Meine ehrliche Frage zu Lakebase ist also nicht, ob die Demo beeindruckend ist. Sie ist, ob das System echte OLTP-Workloads in Produktionsgröße tragen kann, ohne dass dieser Cache zu dem Ding wird, das Menschen um 3 Uhr morgens weckt.
Die multimodalen Daten.
Databricks hat eine starke Karte über OLTP, Warehousing, Echtzeitanalysen, Data Science und Governance hinweg gezeichnet. Aber KI-Anwendungen konsumieren zunehmend Text, Bilder, Audio, Video, Embeddings, Verhaltensprotokolle und Agent-Traces. Das sind nicht einfach Objekte, die neben Tabellen liegen. Sie sind die Daten, die Agenten abrufen, über die sie schlussfolgern, die sie transformieren und zurückschreiben.
Wenn multimodale Daten außerhalb der Kernkarte bleiben, dann leben die wichtigsten KI-Datenbestände weiterhin am Rand.
Der Standardnutzer.
Ein Großteil der Produktoberfläche setzt weiterhin einen menschlichen Nutzer voraus: Dashboards, BI in natürlicher Sprache, Excel-ähnliche Workflows und auf Analysten ausgerichtete Erfahrungen. Diese sind wertvoll. Aber Agenten nutzen Datenbanken anders.
Ein Agent öffnet nicht einmal am Tag ein Dashboard. Er läuft in einer Schleife. Er ruft Kontext ab, trifft eine Entscheidung, ruft ein Tool auf, schreibt Zustand, prüft eine Richtlinie und wiederholt das Ganze. Jeder Schritt muss möglicherweise geprüft werden. Jeder Abruf kann die nächste Handlung beeinflussen. Jeder Schreibvorgang kann ein Rollback benötigen. Jede Berechtigungsprüfung muss möglicherweise zur Laufzeit stattfinden.
Das ist ein anderer Datenbank-Workload.
Foto: Unity AI Gateway · Governance —— Databricks Data + AI Summit 2026
Wenn der Datenbanknutzer ein Agent ist
Über Jahrzehnte konnte sich eine Datenbank im Wesentlichen auf eine Frage konzentrieren: wie diese Abfrage korrekt und schnell auszuführen ist.
Im Zeitalter der Agenten wird die Frage umfassender:
Wie erhält ein Agent in dem Moment, in dem er eine Entscheidung trifft, den aktuellsten, vertrauenswürdigsten, kostengünstigsten und am besten auditierbaren Kontext?
Das ist nicht nur ein Problem der Abfrageoptimierung. Es ist ein Systemproblem über Speicherung, Indexierung, Governance, Herkunftsnachweis, Replay, Kostenkontrolle und Durchsetzung von Laufzeitrichtlinien hinweg.
Hier beginnt sich die Kategorie zu verschieben. Ein Datensystem kann nicht länger nur ein Intelligenzsystem sein: Man stellt eine Frage, es liefert eine Antwort. Es muss eher zu einem Betriebssystem für KI werden: der Ort, an dem Agenten Kontext lesen, Entscheidungen treffen, Tools aufrufen, Zustand schreiben und eine Spur hinterlassen, die Menschen und andere Systeme prüfen können.
Auditierbarkeit kann nicht nachträglich angeflanscht werden. Wenn ein Agent die falsche Antwort gibt, die falsche Aktion ausführt oder zu viel Geld ausgibt, wird die erste Frage lauten: Was genau hat er in diesem Moment gesehen?
Um das zu beantworten, muss das System wissen, welche Dokumente abgerufen wurden, welche Vektoren übereinstimmten, welche Metadatenfilter angewendet wurden, welcher Reranker die Reihenfolge geändert hat, welches Tool aufgerufen wurde, welche Richtlinie durchgesetzt wurde und welcher Zustand zurückgeschrieben wurde. Debugging und Governance werden zum selben Workflow.
Das ist die Architektur, von der ich nicht glaube, dass sie bisher irgendjemand vollständig gelöst hat.
Was „AI-native“ eigentlich bedeuten sollte
„AI-native“ wird zu einem dieser Begriffe, die fast alles bedeuten können. Ich glaube nicht, dass es dafür schon eine klare Definition gibt. Aber wenn wir von realen Agenten-Workloads rückwärts arbeiten, muss ein AI-natives Datensystem zumindest ein paar Dinge gut beherrschen.
Multimodale Daten müssen First-Class sein
Text, Bilder, Audio, Video, Embeddings, Logs und Traces sollten nicht über eine relationale Tabelle, eine Vektorspalte, einen Object Bucket und mehrere Nebenindizes verstreut sein. Sie müssen in einem logischen System leben, in dem Retrieval, Filterung, Ranking und Governance gemeinsam stattfinden können.
Der schwierige Teil ist nicht die Speicherung dieser Assets. Der schwierige Teil ist, sie gemeinsam abfragbar zu machen, ohne die Architektur in ein weiteres Pipeline-Problem zu verwandeln.
Elastizität muss vom Workload ausgehen
Agenten-Traffic ist sprunghaft. Ein System kann eine Stunde lang ruhig sein und dann eine Flut von Retrieval-, Memory- und Tool-Use-Anfragen erhalten. Der Data Lake oder Object Store sollte zur dauerhaften Grundlage werden: günstig, zuverlässig und von Compute entkoppelt.
Aber Compute sollte nicht teuer bleiben, nur weil der Korpus existiert. Wenn niemand sucht, sollte das System sehr wenig ausgeben. Wenn ein Workload aufwacht, sollte Compute schnell bereitstehen. In dieser Welt ist die natürliche Preiseinheit nicht immer ein permanenter Cluster. Es kann die Abfrage, die Sitzung oder die Minute aktiver Compute sein.
Multi-Tenancy muss auf die Agentenebene wandern
Traditionelle Multi-Tenant-Systeme gehen oft von einer überschaubaren Anzahl großer Tenants aus. Agentische Systeme können Millionen oder Milliarden winziger, kurzlebiger, isolierter Zustände erzeugen. Jeder Agent kann sein eigenes Memory, seine eigenen Berechtigungen, Traces, temporären Branches und Schreibpfade mitbringen.
Ein Design, das für Tausende großer Tenants gebaut wurde, wird Schwierigkeiten haben, wenn der Tenant zum Agentenlauf selbst wird.
Branching und Rollback werden zu zentralen Datenbankfunktionen
Agenten werden das Falsche schreiben. Das ist kein Randfall. Es ist Teil des Workloads.
Eine nützliche KI-Datenschicht braucht Git-ähnliches Branching und schnellen Rollback für den Datenzustand. Ein Agentenlauf sollte einen Arbeits-Branch forken, eine Aktion testen, temporären Zustand schreiben und ihn verwerfen oder übernehmen können. Wenn ein fehlerhaftes Update landet, sollte das System schnell zu einem bekannten guten Punkt zurückkehren können.
Versionierung ist nicht mehr nur eine Analytics-Annehmlichkeit. Sie wird zu einem operativen Sicherheitsmechanismus.
Trace und deterministisches Replay sind obligatorisch
Wenn ein Agent scheitert, lautet die Frage nicht nur: „Was war die endgültige Antwort?“ Sie lautet: „Was hat der Agent gesehen, abgerufen, gerankt, entschieden, aufgerufen und geschrieben?“
Dafür braucht es eine Spur jedes bedeutsamen Schritts. Noch wichtiger: Es braucht Replay. Das System sollte in der Lage sein, den Entscheidungskontext so zu rekonstruieren, wie er zu diesem Zeitpunkt existierte, nicht so, wie er aussieht, nachdem ein Dokument geändert oder ein Index neu aufgebaut wurde.
Für Agenten fallen Auditierbarkeit und Debuggbarkeit auf dieselbe Anforderung zusammen.
Berechtigungen müssen Aktionen steuern, nicht nur Zeilen
Traditionelle Autorisierung fragt, wer eine Tabelle, eine Spalte oder eine Zeile lesen darf. Agentische Systeme benötigen eine dynamischere Frage: Was darf dieser Agent in diesem konkreten Schritt abrufen, aufrufen, verändern, offenlegen und ausgeben?
Der schwierige Teil verlagert sich vom Lesepfad auf den Aktionspfad. Policy Enforcement muss erfolgen, während der Agent läuft, nicht nur, wenn ein Mensch ein Dashboard öffnet.
Der Betrieb muss selbstfahrend werden
Skalierung auf Agentenebene sprengt von Menschen betriebene Infrastruktur. Kein Team kann Indizes, Kompaktierung, Cache-Warming, Tenant-Platzierung, Recovery und Ressourcenplanung über Millionen kleiner, sich schnell bewegender Workloads hinweg manuell verwalten.
Das System muss sich selbst betreiben. Andernfalls funktioniert die Architektur vielleicht in einem Diagramm, scheitert aber an dem einzigen Ort, der zählt: in der Produktion.
SQL reicht als finale Schnittstelle nicht aus
Es gibt noch ein weiteres Thema, über das ich immer häufiger nachdenke: die Schnittstelle selbst.
SQL war die richtige Schnittstelle für die Analysten-Ära. Es ist weiterhin essenziell. Aber für Unternehmen, die rund um Datenbanken und Analytics aufgebaut sind, kann SQL auch zu einer Form von Pfadabhängigkeit werden. Die Produktoberfläche, das Nutzermodell und sogar die Organisation gehen oft davon aus, dass der primäre Nutzer jemand ist, der weiß, wie man eine Abfrage schreibt.
Die finale Schnittstelle für Daten im KI-Zeitalter wird kein etwas besserer SQL-Editor sein. Sie wird auch kein Chatbot sein, der vor die Datenbank geklebt wird.
Der interessantere Endpunkt ist ein headless, natürlichsprachlich natives Datensystem: eines, in dem eine Person oder ein Agent die Absicht direkt formulieren kann und das System antworten, handeln oder den richtigen Ausführungsplan vorbereiten kann, ohne jeden internen Schritt als Übung im Schreiben von Abfragen offenzulegen.
Aber das muss nativ in der Datenbank sein, nicht ein separater Agent, der davorsteht.
Wenn natürliche Sprache nur eine Anwendungsschicht ist, führt das System genau die Nähte wieder ein, die es zu entfernen versucht: einen weiteren Übersetzungsschritt, ein weiteres veraltetes Kontextfenster, eine weitere Governance-Lücke. Die Datenbank selbst muss die Frage, die Daten, die Policies und den Ausführungspfad verstehen.
Das ist viel schwieriger, als eine freundliche Schnittstelle zu bauen. Es bedeutet, dass die Datenbank Semantik besitzen muss.
Der Burggraben, der weiterhin zählt
Ich habe keinen vollkommen sauberen Schluss. Vielleicht ist das passend. Der Markt bewegt sich zu schnell, und zu viele alte Annahmen werden schneller als erwartet entleert.
Ein proprietärer Abfragedialekt ist nicht mehr der Burggraben, der er einmal war. Migrationskosten sind schwächer, wenn Agenten Integrationscode neu schreiben können. Eine vertraute UI zählt weniger, wenn der nächste Nutzer vielleicht kein Mensch ist. Selbst der stille Vorteil, einfach die Daten zu besitzen, ist schwächer, wenn offene Tabellenformate, natürlichsprachliche Schnittstellen und werkzeugnutzende Agenten Bewegung erleichtern.
Der Burggraben, an den ich weiterhin glaube, ist weniger glamourös: die Fähigkeit, über einen langen Zeitraum hinweg echten Nutzwert zu schaffen, geduldig und wiederholt.
Deshalb bin ich vom Summit mit dem Eindruck weggegangen, Databricks ernst nehmen zu müssen. Ich denke, Databricks hat eine echte Chance, das nächste Billionen-Dollar-Unternehmen im Datenbereich zu werden. Nicht, weil jede Produktankündigung die endgültige Antwort ist. Manche davon werden sich ändern. Manche werden wahrscheinlich falsch sein. Das ist normal. Entscheidend ist, dass das Unternehmen immer wieder zum richtigen Problem zurückgeht.
Und das richtige Problem ist nicht mehr nur Analytics, Warehousing oder transaktionale Speicherung. Es ist das Datenfundament für KI-Systeme, die handeln.
Aus Sicht von Zilliz sind wir aus einer anderen Richtung zu einem ähnlichen Schluss gekommen. Vektordatenbanken verschwinden nicht. Sie werden zur Serving-Engine innerhalb einer breiteren Architektur für unstrukturierte und multimodale Daten. Deshalb denken wir in Begriffen von Vector Lakebase: kein Ersatz für Vektordatenbanken, sondern die nächste Architektur, die um sie herum aufgebaut ist, da KI-Workloads kontinuierlicher, elastischer und agentischer werden.
Die Landkarte ist noch nicht fertig. Das ist das Beste daran.
Günstig schlägt teuer. Zuverlässig schlägt unzuverlässig. Sorgfältig schlägt nachlässig. Geduldig schlägt ungeduldig.
Die KI-native Datenbank wird noch gezeichnet. Für alle, die in diesem Bereich bauen, sind das sehr gute Nachrichten.
Noch eine Sache: Zilliz Vector Lakebase ist als Public Preview verfügbar
Wir haben die Public Preview von Zilliz Vector Lakebase gestartet — eine bedeutende Weiterentwicklung von Zilliz Cloud von einer reinen Vektordatenbank zu einer lake-nativen Datengrundlage für KI, die latenzarmes Vector Serving mit der Offenheit, Skalierbarkeit und Wirtschaftlichkeit eines Data Lake kombiniert.
Kernfunktionen von Zilliz Vector Lakebase:
- Tiered Serving, optimiert für unterschiedliche Echtzeit-Kompromisse zwischen Performance und Kosten
- On-Demand-Suche für groß angelegte oder explorative Workloads ohne Always-on-Compute
- Suche in externen Data Lakes — direkt über Ihre bestehenden Lake-Daten indexieren und suchen
- Full-Spectrum-Suche über Vektoren, Text, JSON und Geodaten mit Hybrid Retrieval und Reranking
- Einheitlicher lake-nativer Speicher, aufgebaut auf Vortex, einem offenen Format mit schnelleren und günstigeren Random Reads als Lance oder Parquet
Wenn Ihr aktueller Stack Serving und Discovery auf separate Systeme aufteilt, könnte Vector Lakebase einen Blick wert sein. Testen Sie es auf Zilliz Cloud — neue Registrierungen mit beruflicher E-Mail-Adresse erhalten $100 Gratis-Credits — oder sprechen Sie mit uns über Ihren Anwendungsfall.
Weiterlesen
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.
DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding
Explore DeepSeek-VL2, the open-source MoE vision-language model. Discover its architecture, efficient training pipeline, and top-tier performance.