Iceberg, Delta, Hudi: Pick One in 2026 and Move On

The table-format wars are functionally over. Iceberg won on interop. Delta won on installed base. Hudi won on streaming upserts. The decision tree for a new project in 2026 is shorter than the comparison-blog industry wants you to believe.
The war that ended
For five years, choosing a lakehouse table format was a high-stakes, high-confusion decision. Three open formats — Apache Iceberg, Delta Lake, Apache Hudi — each with different metadata layouts, different write semantics, different vendor ecosystems, different decision frameworks pitched by different blog posts on different vendor websites. Picking wrong meant a multi-quarter rip-and-replace.
That war ended in 2024. The endgame move was Databricks' acquisition of Tabular — the company founded by Iceberg's original creators at Netflix — for over $1B (per multiple sources). That acquisition signaled two things at once. First, that Iceberg's momentum was undeniable enough that the company most committed to Delta Lake decided to buy its way into the Iceberg ecosystem rather than keep fighting it. Second, that the future was interoperability rather than format dominance. Databricks immediately built UniForm, which writes Delta tables in a way that exposes them as Iceberg tables to any Iceberg reader. Snowflake added native Iceberg read and write. The format walls came down.
What remained was a much shorter decision tree.
The decision tree
Iceberg won the interop war
The reason Iceberg is the new default is multi-engine support. By 2026, Iceberg can be read and written natively by Spark, Flink, Trino, Presto, Snowflake, BigQuery, DuckDB, ClickHouse, and a long tail of smaller engines. Delta Lake reaches a similar surface only via UniForm or via Databricks-specific runtime. Hudi has the smallest engine surface of the three.
That matters because greenfield architectures in 2026 are not single-engine. The same data needs to be queried by an interactive engine (Trino), a streaming engine (Flink), a notebook engine (DuckDB), and possibly a warehouse (Snowflake) — all without copying. Iceberg is the format every engine has agreed to read. Iceberg's vendor-neutral governance under the Apache Software Foundation, combined with the open architecture of catalog implementations like Polaris and Nessie, means the format is not going to get rugged out from under anyone.
Delta still has the installed base
The case for Delta in 2026 is operational: it is used by over 60% of Fortune 500 companies and 10,000+ organizations, mostly through Databricks' customer base. If you are already on Databricks, switching off Delta is paying real money to solve a problem you don't have. UniForm gives you Iceberg-compatible reads from your existing Delta tables, which closes the interop gap for most use cases.
The case against Delta for greenfield is that the optimization story still favors Databricks Runtime. Delta on open Spark works, but the most-tuned execution path lives behind a Databricks subscription. For organizations that aren't paying that bill, Iceberg's multi-engine performance is more even.
Hudi for the streaming sliver
Hudi is the right answer for a narrow but real use case: high-frequency streaming upserts. The classic shape is CDC ingestion from a high-write OLTP database into a lakehouse, where you need record-level upsert semantics at thousands of records per second with minimal latency. Hudi's merge-on-read tables and built-in indexing infrastructure handle this pattern more cleanly than either Iceberg or Delta.
Outside that sliver, Hudi is the third place. The community is smaller, the engine support is narrower, and the operational tooling lags. If you don't need the streaming-upsert features specifically, picking Hudi in 2026 is choosing a smaller ecosystem for no compensating benefit.
The interop layer is the real story
The most important quiet shift is that Iceberg has become the interoperability lingua franca, and the other two formats are increasingly defined by their relationship to it. Delta Lake's UniForm exposes Delta as Iceberg. Hudi has shipped native Iceberg-compatibility tooling. Even Paimon and DuckLake — the newer entrants — speak Iceberg. The format wars are over not because anyone won, but because Iceberg became the common protocol everyone agreed to read.
For most teams in 2026, the right move is to stop running comparison spreadsheets, pick the answer your decision tree gives you above, and spend the saved cycles on the things that actually differentiate your platform — query patterns, data modeling, governance, observability, cost. The format itself isn't your moat. The pipeline that lands clean data into it is.
Subscribe to new posts from theaivibe.org
Related Posts
The First SQL Engine for Apple Silicon GPUs Is Now a DuckDB Community Extension
In May 2026 I shipped gpudb v0.1 — the first SQL execution engine targeting Apple Silicon GPUs, built as a DuckDB extension with a CUDA backend on Linux. Three releases later, the project crossed two lines at once. v0.3.0's streaming-aggregate rewrite reached parity with native DuckDB on end-to-end TPC-H queries — the worst cell improved roughly 100×, from 11.05 s to 0.109 s. And gpudb became an official DuckDB Community Extension: INSTALL gpudb FROM community now works in any DuckDB ≥ 1.5.5, signed, no flags. This is the full arc — what v0.1 proved, what v0.2 honestly lost, what v0.3 fixed, and why the next GPU frontier is joins.

The Agent-Written Data Pipeline: The Review Bottleneck Nobody Priced In
AI agents can now write dbt models, SQL transforms, and backfills that pass CI and ship. The catch: a wrong number doesn't crash, it quietly poisons every dashboard downstream. The hard part moved from authoring to verification.

We Published Our 110× Loss. One Release Later, It Was Gone.
A reviewer on gpudb's DuckDB community-extensions PR asked the question every GPU project dreads: forget the kernel benchmarks — what does a user actually see end-to-end? We ran it honestly. Native DuckDB won every query shape, by 3× to 109×, against our own extension. We published those numbers in our own release notes — and the act of writing them down produced the structural diagnosis that closed the entire gap in the very next release. The fix was the opposite of what a GPU database is supposed to do: delete the GPU from the hot path. This is the full story, with every number.