Warum offene Datenarchitekturen bei KI jetzt gewinnen

Warum der Markt jetzt Offenheit belohnt

Die eigentliche KI-Entscheidung liegt 2026 oft nicht mehr zuerst beim Modell, sondern bei der Datenarchitektur dahinter. Modelle lassen sich wechseln, kombinieren oder routen. Schwieriger wird es dort, wo Daten, Metadaten, Rechte und Governance in einer Plattform so fest eingebaut sind, dass jeder neue KI-Anwendungsfall erst wieder Daten kopieren, Berechtigungen nachbauen oder neue Silos schaffen muss.

Genau deshalb ist die aktuelle Bewegung bei Snowflake und Databricks mehr als Produktkosmetik. Beide Anbieter rücken offene Tabellenformate, offene Kataloglogik und engine-übergreifende Governance deutlich stärker in den Mittelpunkt. Wenn zwei direkte Rivalen gleichzeitig in diese Richtung laufen, ist das meist kein Zufall. Es ist ein Marktsignal: KI belohnt Architekturen, in denen Daten nicht an ein einziges Ausführungsmodell gebunden bleiben.

Für Unternehmen ist das wichtig, weil KI-Workloads selten sauber in nur einer Engine leben. Ein Team trainiert oder bewertet Modelle vielleicht in einer Spark-Umgebung, ein anderes fragt Daten aus einer Warehouse-Oberfläche ab, ein drittes baut Agenten oder Retrieval-Pipelines darauf. Je mehr diese Workloads zunehmen, desto teurer wird geschlossene Bequemlichkeit.

Die SD-Times-These ist deshalb plausibel: Offenheit wird nicht aus Idealismus wichtiger, sondern aus Betriebsdruck. Snowflake beschreibt seine jüngere Strategie selbst als offenen, interoperablen Rahmen für Daten und KI. Databricks wiederum hat im Mai 2026 Managed Iceberg, Foreign Iceberg und Iceberg v3 in Unity Catalog sichtbar ausgebaut. Beide Signale deuten in dieselbe Richtung: Wer KI produktiv machen will, muss Datenzugriff und Governance portabler machen, nicht enger.

Was Snowflake und Databricks gerade verändern

Snowflake hat 2026 die Unterstützung für Apache Iceberg weiter nach vorn gezogen und verbindet den Horizon Catalog mit Apache Polaris. Zusätzlich ist die Unterstützung externer Query Engines für Apache-Iceberg-Tabellen mit Snowflake Horizon Catalog als allgemein verfügbar dokumentiert. Übersetzt in Alltagssprache heißt das: Daten sollen sich stärker unter gemeinsamer Governance nutzen lassen, auch wenn nicht jede Abfrage in derselben Engine läuft.

Databricks bewegt sich parallel. In den Release Notes vom Mai 2026 tauchen Managed Iceberg, Foreign Iceberg und Iceberg v3 in Unity Catalog als zentrale Ausbaustufen auf. Die zugehörige Dokumentation zu Unity-Catalog-Tabellentypen zeigt außerdem, dass Databricks zwischen Managed, External und Foreign Tables sauber unterscheidet. Auch das ist mehr als Terminologie: Es zeigt, dass Plattformen ihre Datenmodelle auf eine Welt ausrichten, in der Daten nicht nur intern, sondern über mehrere Kontexte hinweg verwaltet werden.

Der strategische Punkt ist nicht, dass Snowflake und Databricks plötzlich identisch werden. Der Punkt ist, dass beide auf dieselbe Realität reagieren: KI macht Datenportabilität, gemeinsame Metadaten und kontrollierten Mehr-Engine-Zugriff wertvoller als eine vollständig geschlossene Plattformlogik.

Wie Iceberg v3 und Polaris zusammenwirken

Um die Bewegung zu verstehen, muss man zwei Schichten auseinanderhalten.

Erstens: das Tabellenformat. Apache Iceberg ist ein offener Tabellenstandard. Vereinfacht gesagt beschreibt er nicht nur Daten, sondern auch, wie sich große analytische Tabellen mit Metadaten, Versionierung und Änderungen sauber organisieren lassen. Für Unternehmen ist das wichtig, weil ein offenes Tabellenformat die Chance erhöht, dieselben Daten mit mehreren Engines zu lesen oder zu verwalten, statt sie für jede Plattform neu zu verpacken.

Zweitens: der Katalog. Ein Katalog ist die Schicht, die beschreibt, wo Tabellen liegen, wie sie heißen, wer darauf zugreifen darf und welche Metadaten oder Governance-Regeln gelten. Apache Polaris positioniert sich genau hier: als offene Katalogschicht für interoperable Iceberg- und Lakehouse-Szenarien. Das Projekt ist also keine komplette Datenplattform, sondern eher die Steuer- und Orientierungsschicht darüber.

Warum ist diese Kombination für KI relevant? Weil KI-Projekte fast nie nur eine Datei lesen und fertig sind. Sie brauchen Datenzugriff, Kontext, Zugriffsrechte, Nachvollziehbarkeit und oft mehrere Verarbeitungspfade. Ein Agent, ein Feature-Job, eine BI-Abfrage und eine Trainingspipeline können auf dieselben Daten zeigen, aber nicht zwingend in derselben Laufzeitumgebung leben. Wenn Tabellenformat und Katalog offener werden, sinkt zumindest die Reibung, diese Welt zusammenzuhalten.

Iceberg v3 ist dabei nicht einfach eine hübsche neue Versionsnummer. Für den Markt ist es vor allem ein Reife- und Standardisierungssignal. Wenn große Plattformanbieter dieselbe Spezifikation aktiv aufnehmen, ist das für Käufer und Architekturteams wichtiger als die Frage, wer das offenere Marketing hat. Es zeigt, welche Standards im Betrieb relevant genug geworden sind, um nicht mehr ignoriert zu werden.

Trotzdem sollte man das nicht romantisieren. Offenes Tabellenformat plus offener Katalog bedeutet noch nicht automatisch, dass jede Engine alle Optimierungen, Sicherheitslogiken oder Betriebsdetails gleich gut beherrscht. Genau diese Lücke ist entscheidend: Offenheit reduziert Reibung, aber sie beseitigt nicht jede Plattformgrenze.

Was das für KI-Teams und Plattformentscheider bedeutet

Für KI-Teams verschiebt sich damit die Bewertungslogik. Die Frage lautet weniger: "Welche Plattform hat die geschlossenste Komplettlösung?" Wichtiger wird: "Wo bleiben Daten, Metadaten und Governance auch dann nutzbar, wenn unser KI-Stack in zwei Jahren anders aussieht?"

Das betrifft mindestens vier praktische Ebenen:

1. Modellwechsel wird einfacher als Datenwechsel. Viele Unternehmen merken bereits, dass Modelle austauschbarer werden. Die zähe Abhängigkeit sitzt daher oft in Datenhaltung, Berechtigung und Metadaten.
2. Governance wird zur KI-Infrastruktur. Wer nicht sauber steuern kann, welche Engine welche Tabellen unter welchen Regeln liest, bekommt kein robustes KI-Betriebsmodell.
3. Weniger Data Movement kann operativ wertvoll sein. Wenn Daten nicht ständig dupliziert oder in neue Formate gedrückt werden müssen, sinken Reibung, Latenz und teils auch Sicherheitsrisiken.
4. Plattformwahl wird langfristiger. Die Architekturfrage entscheidet mit darüber, wie teuer spätere Kurswechsel werden.

Gerade deshalb ist die Entwicklung auch für Leser relevant, die nicht in Data-Engineering-Teams sitzen. Sie berührt Budget, Anbieterabhängigkeit, Compliance und die Geschwindigkeit, mit der neue KI-Anwendungsfälle produktiv werden. Wer das Thema vertiefen will, findet eine naheliegende Anschlussfrage auch in unserem Beitrag Warum KI-Projekte an Infrastruktur und Menschen scheitern.

Welche Fragen Unternehmen jetzt prüfen sollten

Wer gerade eine Daten- oder KI-Plattform bewertet, sollte aus dieser Marktbewegung keine vorschnelle Siegererzählung ableiten. Sinnvoller ist eine nüchterne Prüfliste:

• Wie offen ist nicht nur das Datenformat, sondern auch der Katalog? Ein offenes Tabellenformat allein reicht nicht, wenn Metadaten, Policies und Rechte praktisch an einer Plattform kleben.
• Welche Engines dürfen produktiv auf dieselben Daten zugreifen? Nicht in der Folie, sondern im echten Betrieb.
• Wie viel Governance bleibt erhalten, wenn Teams außerhalb der Kernplattform arbeiten?
• Welche Daten müssen für KI-Workloads heute noch kopiert oder umgebaut werden?
• Wo sitzt der spätere Lock-in eher: im Speicherformat, im Katalog, in Sicherheitsregeln oder in proprietären Zusatzdiensten?
• Wie auditierbar ist das Modell? Gerade für regulierte oder größere Unternehmen wird Governance schnell zur Betriebsfrage statt zum Nebenthema. Dazu passt auch unser Beitrag Warum Compliance-Automation jetzt vom Audit-Problem zum Betriebsmodell wird.

Die vielleicht wichtigste Einordnung lautet am Ende: Offene Datenarchitektur ist kein Selbstzweck und auch kein Freifahrtschein gegen Lock-in. Aber sie wird unter KI-Bedingungen zu einem immer wichtigeren Selektionskriterium. Denn je mehr Daten über verschiedene Tools, Modelle und Laufzeiten hinweg genutzt werden sollen, desto stärker wird geschlossene Bequemlichkeit zum langfristigen Betriebsrisiko.

Genau hier liegt die eigentliche Botschaft hinter Snowflake, Databricks, Iceberg und Polaris. Nicht ein Anbieter öffnet sich plötzlich aus reiner Großzügigkeit. Der Markt selbst drückt in diese Richtung. Und für deutsche Unternehmen ist das keine akademische Standardfrage, sondern eine praktische Architekturentscheidung mit Folgen für Kosten, Wechseloptionen und Governance. Wer die Abhängigkeitsseite davon vertiefen will, sollte auch Warum Cloud-Abhängigkeit für deutsche Unternehmen zum Betriebsrisiko wird lesen.