What a table format actually does
A table format is the layer that sits between raw files in cloud storage and the query engines that read them. Parquet files hold the actual data. The table format tracks which files belong to which table, what schema they follow, and which files represent the current valid version after an update, a delete or a schema change.
Before this layer existed, that job fell to Hive-style metastores, which listed files by folder structure. That approach struggled with concurrent writes, schema evolution and anything beyond simple appends, according to the Apache Software Foundation's own account of the problem Iceberg was built to solve. Apache Iceberg, Linux Foundation Delta Lake and Apache Hudi each add a metadata layer on top of plain files, giving lake storage the transactional guarantees and schema flexibility a database has always had, without moving the data into a proprietary format.
Iceberg, Delta Lake and Hudi: how they differ
Apache Iceberg was built at Netflix and open-sourced to the Apache Software Foundation in 2018 (news.apache.org). Its manifest files store column-level statistics for each data file, so a query engine can rule out irrelevant files before reading anything. It was designed from the start to be read by many different engines rather than one.
Linux Foundation Delta Lake came out of Databricks in 2019. It records every write as a sequential entry in a JSON transaction log, the _delta_log. It performs best inside Databricks' own Photon engine, which reads Delta's native file layout directly rather than through a translation layer.
Apache Hudi came out of Uber and is built around fast, incremental upserts, the pattern of continuously updating a small slice of rows in a very large table, common in change-data-capture pipelines feeding a warehouse from an operational database.
None of the three is simply faster than the others in the abstract. Each optimizes for a different write pattern and a different assumption about which engine reads the data most often.
Why the format war ended in convergence, not a winner
For several years, choosing a table format meant picking a side. That stopped being fully true in 2024 and 2025.
In June 2024, Databricks agreed to acquire Tabular, the company founded by Iceberg's original creators, Ryan Blue and Daniel Weeks. Databricks did not disclose the price. The Wall Street Journal reported it at between $1 billion and $2 billion, a figure also cited by CNBC and TechTarget in their coverage of the deal. The acquisition put the founders of a rival open format inside the company behind Delta Lake.
That same month, Snowflake made Apache Iceberg Tables generally available inside its own platform as part of its 8.20 release, letting customers store Snowflake-managed data in Iceberg's format instead of Snowflake's own proprietary storage (docs.snowflake.com, release dated June 10, 2024).
The following month, Databricks shipped Delta Lake UniForm at general availability. UniForm generates Iceberg metadata automatically alongside every Delta commit, so a single copy of Parquet files can be read by clients built for Iceberg without a separate conversion job (Databricks, GA announced July 9, 2024).
Then, in May 2025, the Apache Iceberg community ratified the version 3 table specification, adding deletion vectors, row-level lineage tracking, client-side encryption and new data types for semi-structured and geospatial data. Databricks, Snowflake and Google all published technical write-ups of the release within weeks of each other. Deletion vectors closed one of the more visible feature gaps with Delta Lake, which had supported them since its own version 2 spec.
Taken together, the two largest warehouse and lakehouse vendors spent roughly a year making sure that whichever format a customer's tools already wrote in, their platform could read it anyway. That is a stalemate rather than a resolution, and it is the reason picking a table format carries less weight in 2026 than it did in 2022.
What to check before committing to one
A vendor's own benchmark comparing table formats is not a reliable input; nearly every vendor's marketing favors its own default format under its own engine. A more useful reference point is a vendor-neutral, reproducible benchmark with a fixed dataset. ClickBench, maintained by ClickHouse and open to submissions from any engine, compares roughly 50 analytical database systems against a fixed 100 GB dataset of real web-traffic data, with the fastest engines currently answering the median query in about 148 milliseconds on a single c6a.4xlarge instance (github.com/ClickHouse/ClickBench). It benchmarks query engines rather than table formats directly, but its published methodology and open dataset are the standard worth demanding before trusting any format-versus-format claim.
Beyond raw speed, three questions matter more for most teams: which catalog manages the table's metadata, since Iceberg REST catalogs such as Polaris and Unity Catalog interoperate more than they did two years ago but not completely; whether the engines already in use can write to the format natively rather than through a connector; and how the format resolves conflicts when multiple jobs write to the same table at once, since Iceberg, Delta Lake and Hudi handle that differently under load.
What still goes wrong
Interoperability at the file and metadata level does not mean tables behave identically everywhere they are read. Photon's vectorized reads are tuned specifically to Delta's native Parquet layout, so inside Databricks, native Delta tables generally still read faster than externally mounted Iceberg tables, even after Iceberg's own performance improved. That is a design tradeoff built into Photon, not a bug waiting to be fixed.
Governance is the other place format choice gets over-weighted. dbt Labs' 2025 State of Analytics Engineering report, based on a survey of 459 data practitioners fielded between October and December 2024, found that building trust in data quality remained data teams' top-ranked challenge, ahead of tooling or format decisions. A well-chosen table format does not fix a broken definition of a customer or a stale transformation model. It just lets more engines read the same wrong answer, faster.