Vom Speicher zum Data Lakehouse

Die Datenabteilung eines Münchner Maschinenbauers verbrachte das gesamte Jahr 2023 damit, einen Data Lake aufzubauen. Auf einem S3-kompatiblen Speicher landeten täglich rund 400 GB neue Maschinendaten, dazu Bestellungen aus SAP, Wartungsprotokolle aus dem Servicesystem und Sensordaten aus den Werkshallen. Alles als CSV. Die ersten Auswertungen funktionierten, doch nach neun Monaten häuften sich die Probleme. Eine Analystin änderte am Quellsystem das Datumsformat, und plötzlich brachen alle nachgelagerten Berichte zusammen. Eine Pipeline schrieb gleichzeitig in dieselbe Datei und zerstörte die Konsistenz. Eine Wirtschaftsprüfung verlangte den Stand vom 31. März und niemand konnte ihn rekonstruieren, weil Dateien überschrieben worden waren. Im Frühjahr 2024 kippte die Geschäftsleitung das Vorhaben und ließ es neu aufsetzen.

Diese Geschichte ist exemplarisch für den Unterschied zwischen einer Sammlung von Dateien und einer echten Datenplattform. Ein Bucket voller CSV ist kein Data Lake, sondern eine Festplatte mit Web-Schnittstelle. Damit aus dem nackten Speicher eine analytisch nutzbare Schicht wird, braucht es zwei Dinge: ein effizientes Dateiformat und eine Tabellenabstraktion, die ACID-Garantien und Schema-Evolution liefert. Genau diese beiden Bausteine bilden zusammen das, was sich seit ungefähr 2022 als Data Lakehouse durchgesetzt hat.

Warum ist Parquet das richtige Format für analytische Daten?

Apache Parquet ist ein offenes, spaltenorientiertes Speicherformat, das ursprünglich aus dem Hadoop-Umfeld stammt und seit Jahren als Industriestandard für analytische Daten gilt. Im Unterschied zu CSV, das Werte zeilenweise als Text ablegt, gruppiert Parquet sie spaltenweise. Eine Tabelle mit den Spalten Datum, Kunde, Artikel, Menge und Umsatz wird nicht als Folge von Zeilen geschrieben, sondern als fünf Blöcke, in denen jeweils alle Werte einer Spalte zusammenstehen. Innerhalb dieser Blöcke werden die Werte zusätzlich kodiert und komprimiert.

Diese Anordnung passt zu der Art, wie analytische Abfragen die Daten lesen. Die Frage nach dem durchschnittlichen Umsatz pro Monat braucht Datum und Umsatz, nicht aber Kunde oder Artikel. Spaltenspeicher liest exakt diese beiden Spalten und überspringt den Rest. Hinzu kommt, dass Werte in einer Spalte typischerweise einen ähnlichen Wertebereich haben (zum Beispiel Datumswerte aus einem definierten Zeitraum oder Geldbeträge in einer einheitlichen Währung), was Komprimierungsverfahren extrem wirksam macht. Parquet-Dateien sind in der Praxis um den Faktor fünf bis zehn kleiner als die entsprechenden CSV-Dateien.

Ein zweiter, oft unterschätzter Vorteil ist die eingebettete Schema-Information. Jede Parquet-Datei trägt im Footer die exakten Datentypen mit sich. Das Datum ist ein echter Datumstyp, der Umsatz eine Dezimalzahl mit definierter Präzision, die Kundennummer eine Ganzzahl. Ein nachgelagertes Werkzeug muss nicht raten oder Konventionen interpretieren. Schließlich erlaubt das Format ein Verfahren namens Predicate Pushdown. Ein Filter wie "Datum gleich März 2026" kann anhand der in der Datei gespeicherten Min- und Max-Werte ganze Datenblöcke überspringen, ohne sie überhaupt zu lesen. Bei großen Datenmengen entscheidet das über Sekunden statt Minuten Antwortzeit.

Genau diese Eigenschaften haben dazu geführt, dass Parquet seit ungefähr 2018 jeden ernstzunehmenden Konkurrenten im analytischen Format-Wettbewerb verdrängt hat. Apache ORC, das aus dem Hortonworks-Umfeld stammt, wird zwar weiter gepflegt, hat aber vor allem in Hadoop-Bestandssystemen Bedeutung. Avro spielt eine Rolle in Streaming-Pipelines, ist aber zeilenorientiert und damit für analytische Abfragen weniger geeignet. Wer heute neu plant, wählt Parquet ohne Diskussion. Bei kommerziellen Tools ist die Unterstützung praktisch durchgängig, von Power BI über Tableau bis hin zu Excel mit aktuellen Importfiltern.

Die Format-Spezifikation entwickelt sich weiter, ohne dass die Bestandsdaten neu geschrieben werden müssen. Im Februar 2026 hat die Apache-Foundation mit parquet-format 2.12.0 einen neuen Variant-Typ für semi-strukturierte Daten standardisiert, der JSON-ähnliche Strukturen deutlich effizienter ablegt als die bisherigen String-Workarounds ^[9]. Dazu kommen die logischen Typen GEOMETRY und GEOGRAPHY für räumliche Daten und erweiterte BYTE_STREAM_SPLIT-Codierungen für numerische Spalten. Solche Erweiterungen sind ein gutes Indiz dafür, dass Parquet als Plattform-Format aktiv weiterentwickelt wird, statt nur eingefroren zu existieren.

Eine kleine Faustregel hat sich in der Praxis bewährt. Wer CSV im Data Lake findet, sollte sie möglichst früh nach der Aufnahme in Parquet konvertieren, am besten direkt in einer Bronze-Schicht. Die Konversion ist einmaliger Aufwand, der Nutzen tritt bei jeder einzelnen späteren Abfrage erneut zutage. Die ursprünglichen CSV-Dateien lassen sich für Audit-Zwecke aufheben, sind aber nicht der Bestand, gegen den analytische Werkzeuge tatsächlich arbeiten sollten.

Welche Tabellenformate bilden die Lakehouse-Schicht?

Parquet allein liefert ein effizientes Dateiformat, aber noch keine echte Tabellenabstraktion. Eine analytische Tabelle besteht in der Praxis aus vielen Parquet-Dateien, die im Lauf der Zeit hinzukommen, geändert oder gelöscht werden. Wer atomare Schreibvorgänge, konsistente Lesevorgänge bei parallelem Zugriff oder das nachträgliche Löschen einzelner Datensätze (Stichwort DSGVO) benötigt, braucht eine Schicht darüber. Diese Schicht heißt Tabellenformat. Die wichtigsten Vertreter sind Apache Iceberg, Delta Lake und Apache Hudi.

Alle drei verfolgen denselben Grundgedanken. Sie führen ein Manifest, das festhält, welche Parquet-Dateien zu einer Tabelle gehören, in welcher Version sie gültig sind und welche Schemafassungen es im Lauf der Zeit gegeben hat. Daraus ergeben sich Funktionen, die ein reines Verzeichnis nicht bieten kann. ACID-Transaktionen sorgen dafür, dass parallele Schreibvorgänge sich nicht gegenseitig zerstören. Schema-Evolution erlaubt das Hinzufügen oder Umbenennen von Spalten ohne komplette Neuanlage der Tabelle. Time Travel ermöglicht das Lesen einer Tabelle zu einem definierten früheren Zeitpunkt, etwa für die Reproduktion eines Quartalsberichts oder die Untersuchung eines Datenfehlers. Genau diese Eigenschaften hätten den Münchner Maschinenbauer aus der Eingangsgeschichte vor mindestens zwei seiner drei Probleme bewahrt.

Ein konkretes DSGVO-Szenario zeigt den Mehrwert besonders deutlich. Ein Onlinehändler aus Köln musste auf Anfrage einer Kundin alle ihre Daten löschen, einschließlich der Bestellhistorie aus den letzten fünf Jahren. In einem reinen Parquet-Verzeichnis hätte das bedeutet, sämtliche Dateien zu lesen, die betroffenen Zeilen herauszufiltern und alles neu zu schreiben. Mit Iceberg lief der Vorgang als gezieltes DELETE in der Tabelle, gefolgt von einer Compaction, die die betroffenen Dateien im Hintergrund neu zusammensetzt. Aus zwei Tagen Aufwand wurden zwei Stunden. Wer in regulierten Branchen arbeitet (Finanz, Gesundheit, öffentliche Verwaltung), wird ohne Tabellenformat schon wegen solcher Anforderungen schnell an Grenzen stoßen.

Die Marktlage hat sich in den vergangenen 22 Monaten dramatisch verändert. Am 4. Juni 2024 kündigte Databricks die Akquisition von Tabular an, dem Unternehmen der ursprünglichen Iceberg-Erschaffer rund um Ryan Blue. Spätere Berichte sprachen von rund 2 Milliarden Dollar Kaufpreis bei nur 40 Mitarbeitern ^[1]. Die Akquisition war ein strategisches Bekenntnis. Databricks hatte vorher Delta Lake als hauseigenes Format verteidigt und positioniert sich seit dem Tabular-Deal explizit als Brücke zwischen beiden Formaten. Im Juni 2025 hat das Unternehmen native Iceberg-Unterstützung über die Unity-Catalog-REST-API ausgerollt ^[2]. Mit Iceberg 1.10 (Sommer 2025) und der laufenden Reifung der V3-Spezifikation steht das Format heute auf Augenhöhe mit Delta. In der Praxis bedeutet das: Wer auf Databricks arbeitet, muss sich nicht mehr für ein Format entscheiden. Beide funktionieren parallel.

Die Daten zur Marktverteilung sind erstaunlich differenziert. Im Dremio-Report zum Stand des Lakehouse-Marktes 2024 nutzten 39 Prozent der Befragten Delta Lake und 31 Prozent Iceberg ^[5]. In den nächsten drei Jahren planten allerdings 29 Prozent eine Iceberg-Adoption, gegenüber 23 Prozent für Delta. Eine spezifische Iceberg-Survey vom Januar 2026 bestätigt, dass die Mehrzahl der Iceberg-Anwender die Performance und Zuverlässigkeit als gut bis sehr gut bewertet, mit Interoperabilität als wichtigstem Argument ^[6]. Iceberg holt also weiter auf, getrieben von der breiteren Engine-Unterstützung und der Vendor-Neutralität ^[7]. Für DACH-Organisationen, die ihre Daten möglichst portabel halten wollen, ist das ein gewichtiges Argument zugunsten von Iceberg.

Apache Hudi ist die dritte Option, die im deutschsprachigen Raum bisher weniger verbreitet ist. Hudi spielt seine Stärken vor allem dort aus, wo viele kleine Update- und Delete-Vorgänge anfallen, etwa in operativen CDC-Pipelines (Change Data Capture). Wer Daten aus einer transaktionalen Datenbank fast in Echtzeit in den Lake spiegeln will, sollte Hudi auf der Liste haben. Mit der Version 1.1 (Anfang 2026 erschienen) hat Hudi ein interessantes Pluggable Table Format Framework eingeführt, das es erlaubt, Hudi-Daten alternativ im Iceberg-Format abzulegen, ohne die Hudi-Indexierung und Concurrency-Kontrolle zu verlieren. Für reine Analytik-Lasten ohne Echtzeitanforderung bleibt es selten die beste Wahl. Vergleichende Auswertungen aller drei Formate finden sich in mehreren Magazin-Beiträgen, die für eine Erstauseinandersetzung sehr nützlich sind ^[8].

Meine ehrliche Empfehlung: Wer 2026 neu beginnt und nicht bereits in einer Databricks-Welt verankert ist, sollte mit Iceberg anfangen. Die Vendor-Neutralität und die Tatsache, dass alle relevanten Engines (Spark, Flink, Trino, Dremio, DuckDB, Polars) das Format direkt sprechen, machen es zur sicheren Wahl. Wer auf Databricks setzt, kann beide Formate parallel betreiben und sich die Entscheidung sparen.

Wie machen Kataloge die Tabellen für die Welt sichtbar?

Über den einzelnen Tabellen sitzt eine weitere Schicht, die manchmal vergessen wird, in der Praxis aber den Unterschied zwischen einem chaotischen Lake und einer beherrschbaren Plattform ausmacht. Diese Schicht heißt Katalog. Ein Katalog verwaltet Tabellennamen, Schemata, Eigentümer und Berechtigungen zentral und sorgt dafür, dass Engines untereinander dieselbe Sicht auf den Datenbestand haben. Der Hive Metastore war jahrelang der Quasi-Standard, ist aber technisch in die Jahre gekommen und gilt unter Architekten zunehmend als Auslaufmodell.

Drei moderne Kataloge prägen 2026 die Diskussion. Apache Polaris ist vom Snowflake-Umfeld initiiert worden, mittlerweile als Apache-Projekt geführt und implementiert die Iceberg-REST-API als vendor-neutralen Standard. Im Januar 2026 erschien Version 1.3, am 21. April 2026 folgte Version 1.4 ^[3]. Die 1.4 hat insbesondere Credential Vending für Azure und Google Cloud Storage gebracht, dazu eine Catalog-Federation, die mehrere Backend-Kataloge in Multi-Cloud-Setups vereint, und CockroachDB als neues JDBC-Backend. Polaris bietet feingranulare Berechtigungen und unterstützt Engines wie Spark, Flink, Dremio, StarRocks und Trino. Unity Catalog ist die Antwort von Databricks und seit 2024 als Open-Source-Projekt verfügbar. Die OSS-Version steht im April 2026 bei 0.3.1, die nächste Major 0.4 mit Managed Locations und vollständiger Spark-Integration ist für die kommenden Monate angekündigt. Project Nessie kommt aus dem Dremio-Umfeld und bringt eine Git-ähnliche Branching-Semantik für Daten mit, was vor allem für reproduzierbare Datenpipelines interessant ist. Aktuelle Version: 0.107.x ^[14].

Die ehrliche Wertung lautet: Wer einen neuen Katalog auswählt, sollte Polaris ernsthaft prüfen. Die Vendor-Neutralität, die offizielle Apache-Foundation-Verankerung und die Geschwindigkeit der Releases sprechen für das Projekt. Unity Catalog ist die richtige Wahl, wenn die Plattform ohnehin auf Databricks läuft. Nessie ist ein Spezialwerkzeug für Teams, die Daten-Branching aktiv nutzen wollen, was in der DACH-Region noch selten ist. Hive Metastore sollte aktiv abgelöst werden, idealerweise im Rahmen einer ohnehin geplanten Migration.

Was DuckLake an Bewegung in den Markt bringt

Am 13. April 2026 hat das DuckDB-Team mit DuckLake 1.0 ein eigenes Lakehouse-Format als produktionsreif markiert ^[4]. Die Spezifikation kam zeitgleich mit der DuckDB-Version 1.5.2 und ist in der ducklake-Erweiterung referenz-implementiert. Das Manifest war bereits im Mai 2025 veröffentlicht worden, eine produktionsreife Version brauchte fast ein Jahr Reifezeit. DuckLake etabliert ein viertes Format neben Iceberg, Delta und Hudi. Es speichert Daten auf Object Storage und greift über SQL darauf zu, ähnlich wie eine traditionelle Datenbank. Den Katalog kann man wahlweise in SQLite, PostgreSQL oder einer DuckDB-Datei führen. Die Besonderheit liegt in der Kompatibilität: DuckLake schreibt seine Delete-Buffers als Iceberg-Puffin-Dateien, was bedeutet, dass andere Iceberg-fähige Engines Tabellen aus DuckLake direkt mitlesen können. Features wie Data Inlining, sortierte Tabellen, Bucket-Partitionierung und Deletion-Buffers gehören zum Standardumfang. Die nächste Version 1.1 ist für September 2026 angekündigt.

Ob DuckLake sich gegen die etablierten Formate durchsetzt, ist zum jetzigen Zeitpunkt offen. Mein Eindruck ist, dass das Format vor allem für kleine bis mittlere Setups interessant wird, die ohnehin auf DuckDB als Engine setzen. Für die großen Enterprise-Plattformen bleibt Iceberg die wahrscheinlichere Wahl, einfach weil es deutlich mehr Engines gibt, die das Format nativ unterstützen. Trotzdem lohnt sich ein Blick auf DuckLake. Das Projekt zeigt, dass die Lakehouse-Idee einfach genug ist, um sich von einer kleinen Engine wie DuckDB realistisch mitzubedienen.

Ein zweiter Aspekt aus dem DuckDB-Ökosystem verdient Aufmerksamkeit. Die Iceberg-Erweiterung von DuckDB unterstützt seit Ende 2025 nicht nur das Lesen, sondern auch INSERT, UPDATE und DELETE auf Iceberg-v2-Tabellen, allerdings vorerst nur auf nicht-partitionierten und nicht-sortierten Tabellen. Im Dezember 2025 wurde zusätzlich ein WebAssembly-Client produktionsreif, mit dem sich Iceberg-Datasets direkt im Browser abfragen lassen, ohne eigene Server-Infrastruktur. Auf der AWS re:Invent 2025 demonstrierte das DuckDB-Team die Integration mit Amazon S3 Tables, was die Browser-Variante um einen reifen Hyperscaler-Katalog ergänzt ^[10]. Für Datenkataloge, die ihre Daten Endnutzern oder Entwicklern explorierbar machen wollen, eröffnet das interessante Möglichkeiten. Eine kleine Plattform für offene Daten kann damit ohne Backend Iceberg-Tabellen direkt aus einem S3-Bucket bedienen.

Fazit und Ausblick

Der Begriff Data Lakehouse ist die Verschmelzung von Data Lake und Data Warehouse. Er drückt aus, dass die Architektur die Flexibilität eines Data Lakes (offene Formate, beliebige Datentypen, günstiger Speicher) mit den Garantien eines Data Warehouses (ACID, Schema, Time Travel, Berechtigungen) verbindet. Im Frühjahr 2026 ist dieser Architekturansatz für die meisten neuen Datenplattformen die Default-Wahl. Wer heute mit einer reinen Data-Warehouse-Architektur (zum Beispiel Snowflake oder BigQuery ohne externen Speicher) plant, muss begründen, warum er nicht offen baut. Die Beweislast hat sich umgekehrt.

Was die Architektur in der Praxis bringt, lässt sich an drei Punkten messen. Erstens entkoppelt sie Speicher und Rechenleistung. Daten liegen in einem günstigen Object Storage und werden von wechselnden Engines gelesen. Zweitens bleibt sie portabel. Eine Iceberg-Tabelle in einem S3-Bucket kann von Spark, DuckDB, Trino oder einem Hyperscaler-Dienst gleichermaßen abgefragt werden. Drittens ermöglicht sie eine klare Schichtentrennung (Bronze für Rohdaten, Silver für aufbereitete Tabellen, Gold für analytisch fertige Datenprodukte), die den Betrieb messbar einfacher macht.

Das Bronze-Silver-Gold-Muster verdient eine kurze Erläuterung, weil es sich als Standardpraxis durchgesetzt hat. In der Bronze-Schicht landen Rohdaten so, wie sie aus den Quellsystemen ankommen. Hier ist die Eingabe-Geschwindigkeit wichtig, nicht die Datenqualität. In der Silver-Schicht werden diese Rohdaten validiert, dedupliziert, mit anderen Quellen verbunden und in eine konsistente Tabellenform überführt. In der Gold-Schicht entstehen schließlich die Datenprodukte, gegen die Berichte, Dashboards und ML-Modelle laufen. Diese Schichtentrennung mag formalistisch wirken, hat sich aber als wirksamer Schutz vor dem klassischen "Data Swamp"-Problem erwiesen, bei dem niemand mehr weiß, welcher Stand der Daten gerade gültig ist. Mehrere große Datenteams in der DACH-Region (Otto, Zalando, Siemens Mobility, Bosch) berichten in Konferenzvorträgen offen, dass dieses Muster ihre Lakehouse-Implementierungen rettet.

Es gibt allerdings Szenarien, in denen ein Lakehouse nicht die richtige Antwort ist. Reines Online Transaction Processing (also viele kleine Schreibvorgänge mit niedriger Latenz) ist mit Iceberg oder Delta technisch zwar machbar, aber unwirtschaftlich. Hier gehört eine klassische OLTP-Datenbank wie PostgreSQL, gegebenenfalls plus eine spezialisierte OLAP-Datenbank für die Analytik. Auch sehr kleine Setups (wenige Gigabyte, ein bis zwei Personen) profitieren selten von der zusätzlichen Komplexität. Hier reicht häufig ein einzelnes DuckDB oder eine Postgres-Instanz, die alle Aufgaben mitbedient. Lakehouse beginnt sich ab dem niedrigen Terabyte-Bereich oder bei mehreren parallelen Konsumenten zu rechnen.

Eine offene Frage bleibt der Katalog. Solange es konkurrierende Standards gibt (Polaris, Unity, Nessie, Hive Metastore), ist die Versprechung der Portabilität nur teilweise eingelöst. Eine Iceberg-Tabelle, die in Polaris registriert ist, lässt sich nicht ohne Aufwand in Unity Catalog überführen. Wer eine Lakehouse-Architektur baut, sollte deshalb die Katalog-Wahl bewusst treffen und im Zweifel die offenste Variante wählen. Ein gut gepflegtes Polaris-Setup ist 2026 die Wahl, die einer offenen Plattform am ehesten entspricht.

Ein letzter Gedanke betrifft die organisatorische Seite. Eine Lakehouse-Architektur ist kein Ein-Personen-Werkzeug. Sie braucht klare Verantwortlichkeiten für Schemata, Berechtigungen und Datenqualität. Größere Organisationen führen dafür das Konzept der Data Products ein, bei dem ein Team für die Bronze- bis Gold-Schicht eines fachlichen Bereichs (etwa Bestellungen, Logistik, Personalwesen) die Verantwortung trägt. Für kleinere Unternehmen reicht oft eine Person mit klarer Mandatslage. Wichtig ist, dass die Verantwortung benannt ist, nicht im Niemandsland zwischen IT, Fachbereich und Data Engineering.

Im nächsten Teil rückt die Verarbeitungsseite in den Fokus. Spark, Polars und DuckDB liefern drei sehr unterschiedliche Antworten auf die Frage, wie aus den Tabellen im Data Lakehouse tatsächlich Auswertungen werden. Welche Engine wann passt, hängt nicht nur von der Datenmenge ab, sondern auch von der Skill-Verfügbarkeit im Team und der angestrebten Antwortzeit. Die Werkzeugauswahl auf dieser Schicht ist 2026 differenzierter geworden, weil eine einzelne Maschine deutlich mehr leistet als die meisten Teams glauben.

Wer die Lakehouse-Architektur bis hierhin verstanden hat, verfügt bereits über das wichtigste konzeptionelle Werkzeug. Die folgenden Teile dieser Serie ergänzen es um die operativen Bausteine, die aus dem Konzept eine produktive Plattform machen. Genau dort entscheidet sich am Ende, ob die Trennung der Schichten in der Praxis trägt oder ob sie zu einer Theorie verkommt, die in der täglichen Arbeit keine Rolle spielt.

Quellen

^[1] Databricks Acquires Tabular, Pressemitteilung 4. Juni 2024, plus Folgeberichte (https://www.databricks.com/blog/databricks-tabular, https://techcrunch.com/2024/08/14/databricks-reportedly-paid-2-billion-in-tabular-acquisition/)

^[2] Apache Iceberg 1.10: Maturing the V3 spec, the REST API, Google Open Source Blog, September 2025 (https://opensource.googleblog.com/2025/09/apache-iceberg-110-maturing-the-v3-spec-the-rest-api-and-google-contributions.html)

^[3] Apache Polaris 1.4.0 Release Downloads, 21. April 2026 (https://polaris.apache.org/downloads/1.4.0/)

^[4] DuckLake v1.0: The Lakehouse Format Built on SQL Reaches Production-Readiness, 13. April 2026 (https://ducklake.select/2026/04/13/ducklake-10/, https://duckdb.org/2026/04/13/ducklake-10)

^[5] State of the Data Lakehouse 2024, Dremio Corp. (https://www.dremio.com/)

^[6] State of the Apache Iceberg Ecosystem 2025/2026 Survey, Datalakehousehub Februar 2026 (https://datalakehousehub.com/blog/2026-02-state-of-the-apache-iceberg-ecosystem/)

^[7] Apache Iceberg 1.10 New Features, Snowflake Engineering Blog, 2025 (https://www.snowflake.com/en/engineering-blog/apache-iceberg-1-10-new-features-fixes/)

^[8] Apache Iceberg vs Delta Lake vs Apache Hudi Feature Comparison, Onehouse, Stand April 2026 (https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison)

^[9] Apache Parquet Format 2.12.0 mit Variant-Type, Februar 2026 (https://parquet.apache.org/blog/parquet-format/, https://github.com/apache/parquet-format/blob/master/CHANGES.md)

^[10] DuckDB-Wasm + Iceberg in the Browser, Dezember 2025 / Januar 2026 (https://duckdb.org/2025/12/16/iceberg-in-the-browser, https://www.infoq.com/news/2026/01/duckdb-iceberg-browser-s3/)

^[11] Delta Lake 4.x Release Notes, März 2026 (https://delta.io/blog/2026-03-01-delta-lake-4-1-0-released/)

^[12] Apache Hudi 2025 Year in Review und Hudi 1.x, Stand April 2026 (https://hudi.apache.org/blog/2025/12/29/apache-hudi-2025-a-year-in-review/)

^[13] Hive Metastore Migration zu REST Catalog, lakeFS Blog 2025/2026 (https://lakefs.io/blog/hive-metastore-why-its-still-here-and-what-can-replace-it/)

^[14] Project Nessie Recent Releases, Stand April 2026 (https://projectnessie.org/releases/)