Open Lakehouse: Was „offen“ wirklich heißt und wo es nur Marketing ist

Ein Anbieter stellt seine Plattform vor. Auf jeder zweiten Folie steht „open“. Offenes Tabellenformat, offener Katalog, offene Standards, freie Wahl bei jedem Werkzeug. Das klingt nach einer Architektur, aus der man jederzeit wieder herauskommt. Sechs Monate später will dasselbe Team eine zweite Query-Engine anbinden, weil ein Fachbereich auf ein anderes Werkzeug setzt. Die Daten liegen tatsächlich offen im Objektspeicher. Trotzdem stellt sich heraus: Die Zugriffsregeln, die Performance-Optimierungen und die halbe Betriebslogik hängen an genau diesem einen Anbieter. Portabel sind die Daten, das System darum herum ist es nicht.

Das Muster wiederholt sich, sobald „offen“ als Verkaufsargument auftaucht statt als prüfbare Eigenschaft. Der Begriff suggeriert eine einzige, klare Zusage. Tatsächlich verteilt sich Offenheit über mehrere Schichten, und ein Anbieter kann eine davon offen halten, während er an der nächsten festhält.

Für ein Entscheider-Team stellen sich dann unbequeme Fragen:

Was genau ist „offen“, wenn ein Anbieter es behauptet?

Reicht ein offenes Tabellenformat, oder hängt der Ausstieg an etwas anderem?

Was kostet ein Wechsel der Engine oder des Katalogs wirklich, in Aufwand und Zeit?

Wem vertrauen wir die zentrale Rechtevergabe und die Geschäftslogik unserer Daten an?

Die These dieses Artikels: „Offen“ beschreibt kein einzelnes Merkmal, es beschreibt ein Schichtmodell. Ein offenes Tabellenformat ist die Voraussetzung, aber längst nicht die ganze Zusage. Lock-In lässt sich nur ausschließen, wenn auch Katalog, Compute und Governance austauschbar bleiben. Wo nur die unterste Schicht offen ist, verkauft ein Anbieter Offenheit und behält die Kontrolle.

Statt „offen“ als ein Wort zu behandeln, lohnt es sich, die Architektur in Schichten zu zerlegen und jede einzeln zu bewerten. Die Industrie-Analystin Nidhi Vichare bringt die zugrunde liegende Dynamik in ihrer Analyse der Katalog-Landschaft auf den Punkt: Technologie konvergiert dort, wo Anbieter sie nicht monetarisieren können, und divergiert dort, wo sie es können. Genau dieses Muster zeigt sich von unten nach oben.

Auf dieser Ebene ist die Offenheit am weitesten gediehen. Daten liegen als offene Dateien (in der Regel Apache Parquet) im Objektspeicher. Die Tabellenformate Apache Iceberg, Delta Lake und Apache Hudi strukturieren diese Dateien zu echten Tabellen mit verlässlichen Schreibvorgängen und Schema-Verwaltung. Iceberg wurde ursprünglich bei Netflix entwickelt und wird heute von der herstellerneutralen Apache Software Foundation verwaltet; es wird von AWS, Snowflake, Google BigQuery, Trino und Spark nativ unterstützt. Delta Lake stammt von Databricks und ging an die Linux Foundation.

Hier ist der Lock-In-Schutz real: Wer eine Engine wechselt, muss die Daten nicht neu schreiben. Die Falle liegt eine Ebene daneben. Anbieter ergänzen ihr bevorzugtes Format um proprietäre Optimierungen, die nicht portabel sind: Databricks etwa Liquid Clustering und Predictive Optimization, Snowflake eine automatische Größenanpassung für verwaltete Iceberg-Tabellen. Das Format bleibt offen, die Beschleunigung daran nicht.

Der Katalog ist das Verzeichnis, das festlegt, welche Engine welche Daten findet, wer Zugriff hat und wie Sicherheit geregelt wird. Die Branche bewegt sich auf eine gemeinsame Schnittstelle zu, die Iceberg-REST-Katalog-Programmierschnittstelle, über die verschiedene Werkzeuge mit verschiedenen Katalogen sprechen können. Auf dieser technischen Ebene gibt es also Bewegung in Richtung Offenheit.

Inhaltlich konvergiert hier aber wenig. Apache Polaris, von Snowflake gestartet, ist im Februar 2026 zum Top-Level-Projekt der Apache Software Foundation aufgestiegen und gilt als herstellerneutral. Unity Catalog von Databricks verwaltet neben Tabellen auch Modelle, KI-Funktionen und unstrukturierte Daten. Das Problem für die Austauschbarkeit: Zugriffsregeln, die in einem Katalog definiert sind, gelten im anderen nicht. Eine Migration von einem Katalog zum anderen kommt heute eher einer Neuimplementierung gleich als einem Export-Import, wie der Vergleich von Snowflake Horizon und Unity Catalog zeigt. Damit ist der Katalog die Schicht, an der sich Lock-In heute entscheidet.

Die gemeinsame Schnittstelle täuscht über diese Hürde hinweg. Selbst wenn zwei Kataloge dieselbe Iceberg-REST-Schnittstelle sprechen, lassen sich Tabellen zwischen ihnen nicht einfach synchronisieren: Die Iceberg-Spezifikation warnt sogar davor, dieselbe Tabelle in mehreren Katalogen zu registrieren, weil Aktualisierungen verloren gehen und die Tabelle beschädigt werden kann. Und die Zugriffsregeln liegen je Katalog getrennt vor, sie gelten im anderen nicht. Eine offene Schnittstelle macht den Datenzugriff also technisch möglich, sie macht den Katalog aber nicht austauschbar. Bei „beide sprechen REST“ als Beleg für Offenheit lohnt deshalb genau hier eine Nachfrage.

Speicher und Rechenleistung sind entkoppelt, also lässt sich für jeden Anwendungsfall die passende Engine wählen: Spark für große Verarbeitungsstrecken, spezialisierte Werkzeuge für Echtzeit-Analysen oder lokale Auswertungen. Übersetzungs-Schichten wie Apache XTable oder Delta UniForm sorgen dafür, dass ein Format auch von Lesern eines anderen Formats verstanden wird, ohne die Daten zu kopieren.

Wie genau eine einzelne Datenkopie sowohl Delta- als auch Iceberg-Leser bedient, führen wir im Überblick zu Delta Lake UniForm aus. Auf der Bewertungsebene zählt: Die Kompatibilität ist oft einseitig. Eine von außen eingebundene Tabelle lässt sich lesen, aber anbieter-spezifische Zusatzfunktionen greifen darauf nicht. Und quelloffene Lese-Bibliotheken hinken im Veröffentlichungstempo oft hinterher, sobald eine Fehlerbehebung außerhalb des Hersteller-Fokus liegt.

Hier ist die Standardisierung am dünnsten, und genau hierhin verlagern die großen Anbieter die Kundenbindung. Offene Tabellenformate liefern die Wartung nicht mit, die ihr Betrieb verlangt: Das Verdichten tausender kleiner Dateien (Compaction), das Umsortieren der Daten für schnellere Abfragen (Clustering) und das Aufräumen veralteter Snapshots und verwaister Dateien (Cleaning) laufen über Dienste, die das Format nur ergänzen. Genau diese Dienste verkaufen die Anbieter als ihr eigentliches Produkt, etwa als „Optimizer“, und sie unterscheiden sich stark und sind nicht portabel. Das offene Format sorgt also dafür, dass die Daten lesbar bleiben, der laufende Betrieb hängt aber am Anbieter. Die Verwaltung von KI-Modellen, Agenten-Werkzeugen und Geschäftslogik ist obendrein überhaupt nicht standardisiert. Wer diese Schicht kontrolliert, bindet den Kunden weit über die reinen Daten hinaus.

Nicht jede Schicht muss für jedes Unternehmen offen sein. Ein Team, das auf absehbare Zeit eine einzige Engine betreibt und keine Multi-Cloud-Strategie verfolgt, zahlt für maximale Offenheit auf jeder Ebene einen Preis in Komplexität, den es nicht braucht. Die Frage lautet nicht „so offen wie möglich“, sie lautet „offen genug für die Szenarien, die realistisch eintreten“.

Drei Prüfschritte ordnen die Entscheidung.

Aus diesen drei Schritten ergibt sich eine nüchterne Haltung. Offenheit ist kein Selbstzweck. Sie ist eine Versicherung gegen einen teuren Ausstieg, und wie bei jeder Versicherung lohnt sich die Frage, gegen welches konkrete Risiko sie schützt und was sie kostet.