Iceberg gewann den Formatkrieg. Jetzt zählt der Katalog

6 Min. Lesezeit

Der Streit, welches Tabellenformat das offene Data-Lakehouse trägt, ist weitgehend entschieden. Apache Iceberg hat sich durchgesetzt. Snowflake, Databricks und Amazon führen die Version 3 ein, Delta Lake nähert sich über UniForm an denselben Nenner an. Damit verschiebt sich die eigentliche Architektur-Entscheidung an eine Stelle, die viele Plattform-Teams noch unterschätzen: den Katalog.

Das Wichtigste in Kürze

• Der Formatstreit ist weitgehend vorbei: Iceberg v3 ist auf Snowflake generell verfügbar, auf Databricks im Public Preview, Amazon S3 Tables ziehen mit. Delta Lake stellt seine Tabellen über UniForm zusätzlich als Iceberg bereit. Das Prinzip heißt: einmal schreiben, aus vielen Engines lesen.
• Der Katalog wird zum neuen Lock-in-Hebel: Die Bindung wandert vom Format zum Dienst, der die Metadaten und die Rechte verwaltet. Polaris, Unity Catalog und AWS Glue ringen genau um diese Schicht.
• Die REST-Spezifikation entscheidet über Freiheit: Wer einen Katalog wählt, der die Iceberg-REST-Schnittstelle vollständig erfüllt, hält Engines und Clouds austauschbar. Wer es nicht prüft, verlagert den Lock-in nur eine Etage höher.

VerwandtCross-Cloud Lakehouse und Egress-Caching  /  BigQuery greift Databricks mit S3-Brücke an

Warum der Formatstreit vorbei ist

Drei Jahre lang war die erste Frage bei jedem Lakehouse-Projekt: Iceberg, Delta Lake oder Hudi? Diese Frage ist weitgehend beantwortet. Für neue offene Lakehouses ist Apache Iceberg der Standardfall. Netflix, Apple, Airbnb und LinkedIn verwalten damit Datenbestände im Petabyte-Bereich. Die großen Plattformen unterstützen das Format inzwischen breit, wenn auch nicht überall lückenlos.

Den Ausschlag gibt Version 3. Iceberg v3 bringt Deletion Vectors, Row Lineage und den Variant-Datentyp nativ mit. Das waren bis vor Kurzem die Punkte, an denen Delta Lake technisch vorn lag. Der Abstand zwischen Delta-Performance und Iceberg-Kompatibilität schrumpft damit deutlich. Snowflake hat v3 im Mai generell verfügbar gemacht, Databricks fährt es im Public Preview, Amazon S3 Tables unterstützen es ebenfalls. Lückenlos ist die Abdeckung noch nicht, AWS Athena etwa liest v3 bislang nicht.

Parallel nähert sich Delta Lake an, statt sich abzugrenzen. Über UniForm stellt ein Team seine Delta-Tabellen zusätzlich als Iceberg bereit und lässt sie so aus Snowflake, BigQuery, Redshift oder Trino lesen. Beobachter erwarten, dass die nächsten Versionen beider Projekte weiter zusammenrücken. Für Anwender heißt das: Die Grundlage ist geteilt, die frühere Wette auf ein einzelnes Format entfällt.

Vier Kataloge, vier Lock-in-Profile

Wenn das Format austauschbar wird, entscheidet der Katalog über den Zugriff. Er hält fest, welche Tabellen existieren, wo ihre Metadaten liegen, wer sie lesen darf und wie Schreibvorgänge sauber serialisiert werden. Genau hier liegt der neue Wettbewerb. Vier Optionen prägen den Markt, jede mit einem eigenen Freiheitsgrad.

1. Apache Polaris als neutrale Referenz. Snowflake hat Polaris 2024 offengelegt und der Apache-Stiftung übergeben, wo es als herstellerunabhängiges Projekt weiterläuft. Polaris setzt die Iceberg-REST-Schnittstelle um, samt Rechte- und Credential-Verwaltung für die zugreifenden Engines. Konsequenz: der geringste strukturelle Lock-in, dafür der Betriebsaufwand eines eigenen Dienstes oder einer verwalteten Variante.
2. Unity Catalog im Databricks-Umfeld. Databricks öffnet Unity Catalog für Iceberg-Clients und teilt Bestände inzwischen live an Snowflake, Trino, Flink oder Spark, ohne Kopien. Konsequenz: starke Governance und Sharing-Funktionen, aber die Schwerkraft zieht zur Databricks-Plattform.
3. AWS Glue mit Katalog-Föderation. Glue spricht per Föderation mit Polaris, Unity Catalog und anderen REST-konformen Katalogen. Konsequenz: wer schon auf AWS sitzt, bindet bestehende Kataloge ein, statt sie abzulösen. Der Umstieg läuft dann schrittweise.
4. Snowflake Open Catalog als verwaltetes Polaris. Für Teams, die Polaris nicht selbst betreiben wollen, liefert Snowflake die gehostete Fassung, Dremio eine weitere. Konsequenz: die Neutralität von Polaris ohne eigene Betriebslast, um den Preis einer Anbieterbeziehung für den Dienst.

Die Einordnung ist unbequem, aber klar: Ein offenes Format schützt nicht automatisch vor Bindung. Der Katalog kann den Lock-in wieder einführen, den das Format gerade aufgelöst hat. Die Katalogfrage gehört deshalb an den Anfang der Architektur.

Quelle: Iceberg-REST-Katalog-Landschaft, Stand Mitte 2026.

Wo die Migration wirklich hakt

Der Wechsel scheitert selten am Format und fast immer an der Governance. Ein Katalog verwaltet nicht nur Tabellennamen, er verteilt auch Zugriffsrechte und temporäre Cloud-Credentials an die abfragenden Engines. Genau dieses Credential Vending muss über Cloud-Grenzen hinweg funktionieren und nachvollziehbar bleiben. Polaris hat in der Version 1.4 vom April dafür nachgelegt, etwa mit Session-Tags für die Zuordnung in den AWS-Audit-Logs und mit gespeicherten Katalog-Metriken.

Der zweite Stolperstein ist der Umstieg selbst. Wer heute Tabellen in Glue, im Hive Metastore oder in einem proprietären Format führt, will nicht in einer großen Migration alles zugleich umstellen. Die Katalog-Föderation ist hier der pragmatische Pfad. Sie erlaubt, einen neutralen Katalog wie Polaris schrittweise einzuführen und die alten Systeme parallel weiterzubetreiben, bis der Schnitt sauber sitzt.

Wichtig bleibt die Kostenseite. Cloud-übergreifende Abfragen sind erst dann günstig, wenn Datenbewegung und Egress mitgedacht sind. Der Katalog regelt den Zugriff. Die Kostenfrage bleibt davon unberührt und gehört in dieselbe Entscheidung.

Was Cloud-Teams jetzt entscheiden

Für Plattform-Teams in der DACH-Region heißt das konkret: Die Formatwahl darf keine lange Debatte mehr auslösen, Iceberg ist gesetzt. Die Energie gehört in die Katalogfrage. Wer maximale Unabhängigkeit von Engines und Clouds will, prüft, ob der Katalog die REST-Spezifikation wirklich vollständig erfüllt. Den Betriebsaufwand einer neutralen Lösung rechnet er dabei ehrlich ein.

Wer bereits tief in einer Plattform steckt, kann deren Katalog nutzen, sollte aber wissen, welche Bindung er damit eingeht. Die Föderation bleibt dabei die Ausstiegsoption. Die entscheidende Prüffrage gilt heute dem Katalog: Wer hält die Schlüssel dazu? Das Format ist zur Nebensache geworden. Cloud-übergreifender Datenzugriff wird gerade zur Voraussetzung dafür, dass KI-Agenten überhaupt auf denselben Bestand zugreifen können.

Häufige Fragen

Was ist ein Iceberg-Katalog eigentlich?

Der Katalog ist der Dienst, der weiß, welche Iceberg-Tabellen existieren, wo ihre aktuellen Metadaten liegen und wer sie lesen oder schreiben darf. Er hält den Zugriff mehrerer Engines auf denselben Datenbestand konsistent. Ohne Katalog bleibt eine Iceberg-Tabelle eine Ansammlung von Dateien ohne verlässliche Klammer.

Ist der Streit Iceberg gegen Delta Lake damit erledigt?

Weitgehend. Delta Lake stellt seine Tabellen über UniForm zusätzlich als Iceberg bereit, sodass Iceberg-Engines sie lesen können. Für neue offene Lakehouses ist Iceberg der Standardfall, die Formatwahl bindet kaum noch.

Warum gilt Apache Polaris als besonders neutral?

Polaris gehört zur Apache-Stiftung und setzt die Iceberg-REST-Schnittstelle um. Es lässt sich selbst betreiben oder als verwalteter Dienst über Snowflake und Dremio beziehen. Dadurch bleibt der Zugriff unabhängig von einer einzelnen Plattform.

Muss ich für einen neutralen Katalog alles auf einmal migrieren?

Nein. Katalog-Föderation erlaubt, einen neutralen Katalog schrittweise einzuführen und bestehende Systeme wie Glue oder den Hive Metastore parallel weiterzubetreiben. So verteilt sich das Risiko, statt in einer großen Umstellung zu kumulieren.

Was hat die Katalogfrage mit KI-Agenten zu tun?

KI-Agenten brauchen verlässlichen, geregelten Zugriff auf Daten, oft über Cloud-Grenzen hinweg. Der Katalog liefert genau diese governte Zugriffsschicht auf einen einzigen physischen Datenbestand. Ohne saubere Katalog-Strategie bleibt cloud-übergreifende Agenten-Analyse Stückwerk.

Bildquelle: KI-generiert (Juli 2026)