Die meisten Artikel über Iceberg und Delta Lake beginnen mit einem Funktionsvergleich. Das ist der falsche Anfang — denn 2026 sehen die Funktionslisten fast identisch aus, und weil den meisten, die diese Frage stellen, nie erklärt wurde, was ein Tabellenformat überhaupt ist.
Fangen wir also dort an, in einfacher Sprache, und vergleichen erst danach.
Was ein Tabellenformat wirklich ist
Sie haben einen Ordner im Objektspeicher. Darin liegen ein paar tausend Parquet-Dateien. Jemand nennt das „eine Tabelle“.
Das ist keine Tabelle. Das ist ein Ordner. Und daraus folgen drei echte Probleme:
Niemand ist sich einig, was drin ist. Eine Query-Engine muss den Ordner auflisten, um es herauszufinden. Schreibt ein Job gerade neue Dateien, sieht ein Leser sie und ein anderer nicht.
Sie können nichts sicher ändern. Eine Zeile zu löschen bedeutet, eine Datei neu zu schreiben. Tauschen Sie sie aus, während ein Leser mitten im Scan ist, sind die Ergebnisse falsch.
Sie können nicht zurück. Überschreiben Sie die Datei von gestern, ist gestern weg.
Ein Tabellenformat ist ein Regelwerk, das genau das löst. Es ergänzt eine Metadatenschicht, die verfolgt, welche Dateien zur Tabelle gehören, wie das Schema aussieht und wie die Tabelle zu jedem Zeitpunkt aussah. Leser fragen die Metadaten, nicht den Ordner.
Mehr ist es nicht. Apache Iceberg und Delta Lake sind zwei konkurrierende Regelwerke für dieselbe Aufgabe. Die Daten darunter sind in beiden Fällen weiterhin Parquet.
Die Antwort in 30 Sekunden
Falls Sie hier aufhören wollen:
- Schon auf Databricks? Delta Lake. Es ist das native Format, die Integration ist dort am tiefsten.
- Maximale Engine- und Anbieterunabhängigkeit? Iceberg. Es hat die breiteste Streuung unabhängiger Engines und Kataloge.
- Neuanfang ohne starke Bindung? Iceberg ist 2026 die sicherere Voreinstellung, weil mehr unabhängige Engines es nativ sprechen.
- Tief in Delta und besorgt wegen Lock-in? Möglicherweise müssen Sie gar nicht wechseln — siehe UniForm weiter unten.
Alles Weitere ist die Begründung.
Woher sie kommen, und warum das noch zählt
Dieser Teil erklärt die meisten Unterschiede.
Iceberg ist ein Projekt der Apache Software Foundation. ASF-Governance bedeutet, dass kein einzelner Anbieter die Spezifikation kontrolliert — und das zeigt sich im Ökosystem: BigQuery, Snowflake, Redshift, Athena, Trino, ClickHouse, DuckDB, Dremio, StarRocks, Doris, Druid, Firebolt und Microsoft OneLake lesen es alle, und die Katalogschicht hat mehrere unabhängige Implementierungen, darunter Apache Polaris, Apache Gravitino, AWS Glue, Nessie und Lakekeeper.
Delta Lake entstand bei Databricks und wurde 2019 zu einem Projekt der Linux Foundation. Das Projekt schreibt unmissverständlich, es sei „ein unabhängiges Open-Source-Projekt und wird nicht von einem einzelnen Unternehmen kontrolliert“, und nennt über 190 Entwickler aus mehr als 70 Organisationen. Sein Schwerpunkt liegt aber weiterhin bei Databricks, und die aktivste jüngere Entwicklung — die Unity Catalog Delta APIs — steht Databricks nahe.
Was das praktisch bedeutet: Wenn Ihre Sorge lautet „kann ich meine eigenen Daten in fünf Jahren mit einem Werkzeug lesen, das ich noch nicht gewählt habe“, ist Icebergs Governance die konservativere Wette. Ist Ihre Plattform ohnehin Databricks, ist diese Sorge weitgehend theoretisch und Delta bietet den besseren Alltag.
Was tatsächlich gleich ist
Mehr, als das Marketing nahelegt. Beide bieten:
| Fähigkeit | Was das heißt |
|---|---|
| ACID-Transaktionen | Schreiber zerstören sich nicht gegenseitig; Leser sehen einen konsistenten Snapshot |
| Time Travel | Die Tabelle abfragen, wie sie gestern aussah; einen fehlerhaften Ladelauf zurückrollen |
| Schema-Evolution | Spalten hinzufügen, umbenennen, löschen und umsortieren, ohne Daten neu zu schreiben |
| Zeilenweise Löschungen und Updates | Einzelne Zeilen ändern, ohne ganze Dateien neu zu schreiben |
| Streaming und Batch | Dieselbe Tabelle bedient beides |
| Parquet darunter | Ihre eigentlichen Datendateien sind in beiden Fällen dieselben |
Wenn Ihnen jemand eines davon als Alleinstellungsmerkmal verkauft, verkauft er Ihnen etwas.
Was tatsächlich anders ist
Drei Dinge unterscheiden sich wirklich.
1. Iceberg verbirgt die Partitionierung, Delta nicht.
Das ist Icebergs nützlichstes Alleinstellungsmerkmal und das, dessen Verständnis sich am meisten lohnt.
In älteren Systemen musste eine Abfrage explizit auf die Partitionsspalte filtern, sonst wurde alles gescannt. Nutzer mussten das physische Layout kennen.
Iceberg hinterlegt die Transformation — „partitioniere nach Tag dieser Zeitstempelspalte“ — als Tabellenkonfiguration. Sie schreiben einen normalen Filter auf den Zeitstempel, und Iceberg leitet den Partitionsfilter ab und überspringt Dateien für Sie.
Noch besser: Es unterstützt Partition Evolution. Beginnen Sie mit Monatspartitionen, stellen Sie fest, dass die Daten gewachsen sind, wechseln Sie auf Tage — ohne die bestehenden Daten neu zu schreiben. Alte Dateien behalten ihr altes Schema, neue nutzen das neue, und Abfragen funktionieren weiter, weil Filter abgeleitet und nicht fest verdrahtet sind.
2. Delta beantwortet Interoperabilität mit UniForm.
Deltas Antwort auf „aber alle anderen nutzen Iceberg“ ist das Delta Universal Format. UniForm erlaubt es, Delta-Tabellen mit Iceberg- und Hudi-Clients zu lesen.
Das ist ein ausgesprochen pragmatischer Zug. Hat Ihre Organisation vor drei Jahren auf Delta standardisiert, brauchen Sie nicht zwingend ein Migrationsprojekt — womöglich genügt es, UniForm einzuschalten und Iceberg-sprechende Engines lesen zu lassen, was ohnehin da ist.
3. Delta liefert einen Kernel, den Engines einbetten.
Delta pflegt einen Kernel, unter anderem in Rust, den andere Engines einbetten können, statt das Protokoll neu zu implementieren. ClickHouse hat den Rust Delta Kernel dieses Jahr integriert. Das senkt die Hürde für neue Engines, Delta korrekt zu unterstützen — wichtig, weil in Protokoll-Neuimplementierungen die subtilen Fehler wohnen.
Was tatsächlich entscheidet
Hier kommt der Teil, den die meisten Vergleiche auslassen.
Sie werden Ihr Tabellenformat leichter wechseln als Ihren Katalog.
Der Katalog verfolgt, welche Tabellen existieren, wo deren Metadaten liegen und wer sie lesen darf. Iceberg hat genau dafür eine REST-Catalog-Spezifikation, um das zu entkoppeln, und es gibt mehrere Implementierungen. Deltas jüngste Arbeit dreht sich um die Unity Catalog Delta APIs.
Ihr Katalog hängt an Ihrem Berechtigungsmodell, Ihrem Lineage-Tooling, Ihrer CI und jeder Pipeline, die Sie betreiben. Ein Tabellenformat zu migrieren ist ein dokumentiertes Verfahren — Iceberg veröffentlicht sogar einen Delta-Lake-Migrationsleitfaden. Einen Katalog zu migrieren ist ein Projekt.
Das ehrliche Entscheidungsverfahren lautet also:
- Welcher Katalog wird diese Daten verwalten? Lautet die Antwort Unity Catalog, sind Sie bei Delta. Lautet sie Polaris, Glue, Gravitino, BigLake oder Nessie, sind Sie bei Iceberg.
- Welche Engines müssen lesen? Listen Sie sie auf und prüfen Sie, welches Format jede nativ spricht — nicht über eine Brücke.
- Erst dann schauen Sie auf Funktionen.
Wer direkt zu Schritt 3 springt, trifft eine Entscheidung, die Schritt 1 sechs Monate später still überstimmt.
Welche Spezifikationsversion
Erwähnenswert, weil es regelmäßig für Verwirrung sorgt.
Bei Iceberg sind die Spezifikationsversionen 1, 2 und 3 vollständig und von der Community übernommen. Version 3 brachte erweiterte Typen (Nanosekunden-Zeitstempel, Variant, Geometry und Geography), Standardwerte für Spalten, Row-Lineage-Tracking und binäre Deletion Vectors. Version 4 befindet sich in aktiver Entwicklung und wurde nicht formal übernommen — sie strukturiert Metadaten um und führt relative Pfade ein, damit Tabellen verschoben werden können, ohne Metadaten neu zu schreiben. Planen Sie noch nicht damit.
Bei Delta Lake ist die aktuelle Linie 4.4.0 auf Apache Spark 4.2.0.
Die Entscheidungstabelle
| Ihre Situation | Wahl |
|---|---|
| Databricks ist Ihre Plattform | Delta Lake |
| Mehrere Query-Engines, mehrere Anbieter | Iceberg |
| BigQuery oder Snowflake als primäres Warehouse | Iceberg — beide lesen es nativ |
| Sie müssen die Partitionierung später ändern | Iceberg — Partition Evolution |
| Schon auf Delta, brauchen Iceberg-Leser | Bei Delta bleiben , UniForm aktivieren |
| Governance und Anbieterneutralität haben Priorität | Iceberg — ASF-Governance |
| Neuanfang, keine Randbedingungen | Iceberg — breitere native Unterstützung |
| Ihr Katalog ist Unity Catalog | Delta Lake — die Entscheidung ist bereits gefallen |
Wenn Sie noch entscheiden, was über dem Tabellenformat sitzt: Der Warehouse-Vergleich in BigQuery vs. Snowflake behandelt die Schicht, die diese Tabellen konsumieren wird.
Das Fazit
Der Formatkrieg ist leiser, als die Blogposts vermuten lassen. Beide Formate erledigen dieselbe Kernaufgabe, beide sind produktionsreif, und die Interoperabilitätsschichten sorgen dafür, dass eine „falsche“ Wahl heilbar bleibt.
Nicht günstig heilbar sind dagegen eine Katalogentscheidung, eine Engine-Festlegung oder ein Berechtigungsmodell auf der falschen Annahme. Entscheiden Sie diese zuerst, dann entscheidet sich das Tabellenformat meist von selbst.
Und wenn Sie eine technische Sache mitnehmen: Hidden Partitioning und Partition Evolution sind der echte Iceberg-Vorteil. Nicht weil sie aufregend wären, sondern weil „wir haben das vor zwei Jahren falsch partitioniert und können es ohne Neuschreiben nicht korrigieren“ ein wirklich teurer Satz ist — und Iceberg ist dasjenige, das Ihnen erspart, ihn zu sagen.
Ursprünglich veröffentlicht auf alekseialeinikov.com
Top comments (0)