Oracles Lakehouse-Wette: 63 % der Unternehmen sind nicht KI-bereit

Dreiundsechzig Prozent der Unternehmen verfügen entweder nicht über die richtigen Datenverwaltungspraktiken für KI – oder wissen es schlicht nicht. Diese einzelne Gartner-Zahl, die Oracle in der Launch-Kommunikation zu Autonomous AI Lakehouse zitiert, ist die entscheidende Kennzahl. Sie positioniert das Produkt nicht als Warehouse-Upgrade, sondern als Wette: Die meisten Unternehmen werden ihren Datenbestand niemals auf einer einzigen Plattform konsolidieren, und die überlegene Architektur ist jene, die quer durch das Datenchaos hinweg abfragt – anstatt es zu beseitigen.

Die Umbenennung von Autonomous Data Warehouse in Autonomous AI Lakehouse ist Oracles Antwort der zweiten Generation auf Snowflake und Databricks. Interessant ist die zugrunde liegende Annahme: Interoperabilität zuerst, Migration danach – oder gar nicht.

Die Zahlen

Beginnen wir damit, was tatsächlich behauptet wird. Wie Oracle Blogs am 24. September berichtete, unterstützt AI Lakehouse drei Einstiegspunkte: die Modernisierung eines lokalen Oracle-Warehouse, die Erweiterung der Autonomous Database oder die Verknüpfung von Oracle-Daten mit extern gespeicherten Daten. Zwei dieser drei Wege setzen explizit voraus, dass der Kunde keine Konsolidierung vornimmt. Das ist eine erhebliche Positionsverschiebung gegenüber dem klassischen Warehouse-Versprechen des letzten Jahrzehnts, das sinngemäß lautete: „Bringen Sie alles hierher."

Die Gartner-Zahl von 63 % ist der Anker. Liest man sie genau: Sie besagt nicht, dass 63 % der Unternehmen schlechte Datenpraktiken für KI haben. Sie besagt, dass 63 % sie entweder nicht haben oder nicht wissen, ob sie sie haben. Der „weiß-nicht"-Anteil ist die kritischere Hälfte, denn er impliziert, dass die Governance- und Lineage-Werkzeuge für eine Selbsteinschätzung fehlen. Genau diese Lücke adressiert AI Data Catalog mit seiner Catalog-of-Catalogs-Architektur, die Metadaten aus AWS Glue, Databricks Unity Catalog und Snowflake Horizon Catalog in einer einheitlichen Ansicht zusammenführt.

Auf der Abfrageseite nennt die Quelle zwei Performance-Features mit unterschiedlichen Aufgaben. Lake Cache speichert häufig abgerufene externe Daten lokal innerhalb von AI Lakehouse. Data Lake Accelerator fügt temporär Rechenkapazität für große Scans externer Daten in Object Storage hinzu und gibt diese Ressourcen nach Abschluss der Abfrage wieder frei. Das sind zwei verschiedene Problemstellungen: Cache dient wiederkehrenden kleinen Lesevorgängen, Accelerator dient Burst-Scans. Der einzige veröffentlichte Kundendatenpunkt ist SKY Brazil, das in frühen Tests verbesserte Abfragegeschwindigkeiten für externe Daten im Object Storage meldete und On-Demand-Skalierung zur Kostenkontrolle nutzte.

Die Quelle gibt das Ausmaß der Verbesserung bei SKY Brazil nicht preis – was relevant ist, da „verbessert" in dieser Kategorie alles zwischen 1,2x und 100x bedeuten kann. Ohne Prozentzahl, Benchmark-Set oder Vergleichsengine ist dies ein Erfahrungsbericht, kein Benchmark. Eine nützliche Einschätzung: Wenn Data Lake Accelerator mit den führenden External-Table-Engines bei TPC-DS-ähnlichen Workloads über Iceberg mithalten kann, sollte Oracle innerhalb von zwei Quartalen konkrete Multiplikatoren veröffentlichen. Bleibt das aus, sind einstellige Verbesserungen bei Cold Scans anzunehmen.

Was wirklich neu ist

Streicht man das Marketing heraus, sind drei Dinge in diesem Release im Vergleich zur bisherigen Autonomous Data Warehouse-Positionierung genuinely anders.

Erstens: native Apache Iceberg-Unterstützung. Das ist inzwischen Grundvoraussetzung, signalisiert aber, dass Oracle akzeptiert hat, dass der Krieg um offene Tabellenformate vorbei ist – und Iceberg gewonnen hat. Für Teams, die bereits über Databricks oder Snowflake auf Iceberg standardisiert sind, bedeutet das, dass Oracle aufhört, eine Dateninsel zu sein. Ob Oracles Iceberg-Implementierung die vollständige Spezifikation unterstützt – einschließlich Hidden Partitioning, Edge Cases bei Schema Evolution und Time-Travel-Semantik – wird in der Quelle nicht thematisiert. Das ist der erste Punkt, den Engineering-Teams in einem POC prüfen sollten.

Zweitens: das Catalog-of-Catalogs-Muster. Anstatt Unity Catalog oder Horizon zu ersetzen, föderiert Oracle sie. Das ist architektonisch sinnvoll und politisch klug. Es räumt auch ein, dass Oracle nicht der primäre Catalog für ein modernes Data-Team sein wird, das bereits Databricks betreibt. Die Wette lautet: Governance-intensive Unternehmen brauchen einen Super-Catalog oberhalb der Plattform-Catalogs, und Oracle will diese Schicht besetzen.

Drittens: Das Converged-Engine-Versprechen wird für das KI-Zeitalter überarbeitet. Die Quelle beschreibt relationale, JSON-, Graph-, Spatial-, Vektor- und XML-Daten auf einer gemeinsamen Grundlage, die denselben Transaction Manager, Optimizer und dieselben Zugriffskontrollen teilen. Der Vektor-Aspekt ist das Neue gegenüber der Vorgängergeneration. AI Vector Search findet relevante Informationen auf Basis von Bedeutung statt exakter Schlüsselwortübereinstimmungen, und Select AI übersetzt natürlichsprachliche Fragen in SQL. Beides ist 2026 nicht einzigartig für Oracle. Was möglicherweise einzigartig ist: beides gegen dieselbe Governance-Oberfläche wie die OLTP-Daten auszuführen – ohne separate Vektordatenbank.

Deep Data Security, das Zugriffsrichtlinien direkt in der Datenbank durchsetzt und sie auch auf KI-Agenten anwendet, die im Auftrag eines Nutzers handeln, ist das Detail, das Beachtung verdient. Agent-scoped Access Control ist der Bereich, in dem die meisten Stacks derzeit mit behelfsmäßigen Lösungen zusammengehalten werden. Wenn Oracle dies auf Datenbankebene statt im Anwendungscode durchsetzen kann, ist das ein echter Vorteil für regulierte Branchen.

Was Data Teams bereits eingepreist haben

Die meisten erfahrenen Data Engineers haben Datenföderation und Iceberg-Unterstützung bereits erwartet. Dieser Zug hatte den Bahnhof verlassen, als Snowflake Iceberg Tables einführte und Databricks sich zu Unity Catalog OSS bekannte. Dass Oracle Ende 2026 mit denselben Fähigkeiten aufwartet, ist kein Führungsschritt, sondern ein defensiver. Der Markt hat das bereits eingepreist.

Ebenfalls eingepreist: Natural-Language-to-SQL. Select AI ist solide Grundvoraussetzung, keine Differenzierung. Jeder Warehouse-Anbieter hat das in irgendeiner Form geliefert. Die interessante Frage ist die Genauigkeit bei komplexen Joins über föderierte Quellen hinweg – die die Quelle nicht benchmarkt.

Was nicht eingepreist ist – und was tatsächlich von Bedeutung sein könnte – ist die Catalog-of-Catalogs-Wette. Die vorherrschende Annahme im modernen Data Stack lautet, dass dbt's Semantic Layer, Unity Catalog oder Horizon jeweils als Governance-Wurzel für ihre jeweiligen Plattformen dienen, während leichtgewichtige Cross-Platform-Tools die Föderation übernehmen. Oracle argumentiert, dass es eine schwergewichtigere Governance-Schicht oberhalb all dieser Systeme braucht. Wenn regulierte Branchen zustimmen, ist das ein echter Land Grab. Wenn nicht, wird AI Data Catalog zu einem weiteren Metadaten-Silo in einem Raum voller Silos.

Der weitere unterschätzte Aspekt ist das Release-on-Query-Completion-Verhalten von Data Lake Accelerator. Ephemerer Burst-Compute für große Scans ist das, was die meisten Teams von einem Lakehouse tatsächlich wollen: für den Scan bezahlen, nicht für einen permanenten Cluster. Ob Oracles Preismodell dieses Versprechen einlöst, ist die offene Frage. Die Query-Kosten pro Abfrage gehen aus der Quelle nicht hervor.

Die Gegenmeinung

Die Konsens-Lesart dieser Ankündigung wird lauten: „Oracle holt auf." Ich würde argumentieren, dass die interessantere Lesart ist, dass Oracle sich still und leise um eine These neu positioniert, die die meisten Anbieter ablehnen: dass Unternehmen sich niemals vollständig modernisieren werden.

Snowflake und Databricks haben ihre Geschäfte auf der gegenteiligen Prämisse aufgebaut: dass Kunden Workloads schrittweise auf ihre Plattform migrieren, bis das Legacy-System abstirbt. Oracle verkauft jetzt an den CIO, der drei Jahre Migrationsrechnungen gesehen hat, beobachtet, wie das On-Premises-Oracle-Warehouse noch immer das Hauptbuch führt, und entschieden hat, dass die Migration in diesem Jahrzehnt nicht abgeschlossen sein wird. Für diesen Käufer ist „Erweitern Sie, was Sie haben, und föderieren Sie den Rest" ein ehrlicheres Versprechen als „Lift and Shift in 18 Monaten."

Das Gegenrisiko besteht darin, dass diese Haltung zur selbsterfüllenden Stagnation wird. Datenföderation ist architektonisch elegant und operativ aufwendig. Cross-Catalog-Lineage, cross-engine Query-Optimierung und konsistente Sicherheitssemantik über AWS Glue, Unity und Horizon hinweg sind ungelöste Probleme im großen Maßstab. Wenn AI Lakehouse das Marketing liefert, aber nicht die operative Tiefe, erhalten Kunden das Schlechteste aus beiden Welten: ein Lakehouse, das einheitliche Analytics verspricht, aber Engineers zwingt, über drei Catalogs und vier Query-Engines nachzudenken. Dieses Scheiterszenario ist wahrscheinlicher, als der Anbieter einräumt.

Offene Fragen

Einige Kennzahlen, die es sich lohnt zu verfolgen. Die Quelle erwähnt Autonomous Data Guard mit automatischem Failover und nennt für geeignete AI Lakehouse-Deployments ein SLA von 99-Komma-irgendwas – die genaue Zahl ist im Quelltext abgeschnitten. Das ist keine triviale Auslassung. Der Unterschied zwischen 99,9 %, 99,95 % und 99,99 % entspricht ungefähr einer Größenordnung an tolerierbarer Ausfallzeit pro Jahr, und Enterprise-Käufer kalkulieren Verträge auf Basis dieser Zahl. Bis Oracle das vollständige SLA veröffentlicht, ist vom konservativen Mindestwert auszugehen.

Ebenfalls unbekannt sind die Preisgestaltung für den Burst-Compute von Data Lake Accelerator, die Genauigkeit von Select AI bei föderalen Abfragen über drei Catalogs hinweg sowie ob die AI Vector Search-Performance bei Vektoren im Milliardenmaßstab mit spezialisierten Vektordatenbanken mithalten kann. Jede dieser Fragen lässt sich in einem zweiwöchigen POC beantworten. Wenn Oracle zuversichtlich ist, sind bis Q1 2027 veröffentlichte Benchmarks zu erwarten. Falls bis Mitte 2027 keine erscheinen, lautet die stille Antwort, dass die Zahlen nicht schmeichelhaft sind.

Die wichtigsten Erkenntnisse

• Die 63-%-Zahl ist das eigentliche Verkaufsargument. Oracle richtet sich an die Mehrheit der Unternehmen, die einräumen, datenseitig nicht KI-bereit zu sein, und verkauft Datenföderation als Abkürzung.
• Zwei von drei Einstiegspunkten setzen keine Migration voraus. Das ist eine bedeutende Positionsverschiebung und bringt Oracle in direkten Wettbewerb mit der „Erweitern, nicht ersetzen"-Philosophie statt mit dem Konsolidierungsversprechen.
• Catalog-of-Catalogs ist der Differenzierungsfaktor, den es zu beobachten gilt. AWS Glue, Unity Catalog und Horizon in einer Governance-Schicht zu verbinden, ist entweder ein Land Grab oder ein weiteres Silo. Das hängt von einer operativen Tiefe ab, die Oracle noch nicht öffentlich demonstriert hat.
• SKY Brazils Erfahrungsbericht fehlen Zahlen. „Verbesserte Abfragegeschwindigkeiten" ohne Multiplikator oder Baseline ist ein Datenpunkt, kein Benchmark. Im POC sollten konkrete Zahlen gefordert werden.
• Die fehlende SLA-Stelle und das fehlende Preisdetail sind die Warnsignale. Verfolgen Sie, ob Oracle innerhalb von zwei Quartalen das vollständige SLA, die Burst-Compute-Preisgestaltung und Genauigkeitsbenchmarks für Select AI veröffentlicht. Schweigen bis Mitte 2027 ist die Antwort.