Best data lake table format 2026

Summary

• No single table format is best for every workload. Apache Iceberg, Delta Lake and Apache Hudi are the three open formats compared here, and each project's repository carries the Apache License 2.0.
• They describe themselves differently. Iceberg calls itself an open table format for huge analytic datasets, Delta Lake an open-source storage framework, and Hudi an open data lakehouse platform whose table format targets incremental data pipelines.
• All three document transactions, time travel and support for Apache Spark, Apache Flink and Apache Hive. They differ in how they record table state, handle row-level changes and read only what changed.
• Decide on your write pattern, downstream readers and engines, then test your own workload. This page makes no performance claims.
• On Databricks, Delta Lake is the default format, and Unity Catalog also supports managed and foreign Iceberg tables.

Best data lake table format 2026
As of October 2026 there is no single best open table format. The right one depends on your write pattern, your readers and your engines. The three formats compared here are Apache Iceberg, Delta Lake and Apache Hudi. Iceberg and Hudi are Apache Software Foundation projects. Delta Lake is a Linux Foundation project that calls itself "an independent open-source project and not controlled by any single company". All three repositories use the Apache License 2.0.

How do the three formats differ?

Aspect	Apache Iceberg	Delta Lake	Apache Hudi
Describes itself as	An open table format for huge analytic datasets	An open-source storage framework	An "open data lakehouse platform", with a table format "purpose-built for high performance writes on incremental data pipelines"
Table state	Metadata files; each change creates a new metadata file swapped in atomically	JSON commit files in the _delta_log directory	A timeline, a log of all actions on the table at different instants
Concurrency	Serializable isolation; concurrent writers use optimistic concurrency and retry	Optimistic concurrency control; a conflicting write fails with an exception	Snapshot isolation; optimistic concurrency control between writers, MVCC between writers and table services
Row-level changes	Can eagerly rewrite data files or use delete deltas	Rewrites the Parquet file for a deleted row by default; with deletion vectors enabled, some operations mark rows removed without rewriting	Copy On Write rewrites base files; Merge On Read writes log files merged at query time
Time travel	VERSION AS OF or TIMESTAMP AS OF in Spark SQL	VERSION AS OF or TIMESTAMP AS OF, plus the versionAsOf and timestampAsOf reader options	TIMESTAMP AS OF in SQL
Reading only changes	start-snapshot-id and end-snapshot-id read options, appended data only	Change data feed, off by default	Incremental and CDC queries through hudi_table_changes

Each project's docs list Apache Spark, Apache Flink and Apache Hive among the supported engines.

Which questions should drive the decision?

Question	What to look for
Do you update or delete individual records often?	Compare Iceberg delete deltas, Delta Lake deletion vectors and Hudi's Merge On Read table type against rewriting data files
Do downstream jobs need only the rows that changed?	Compare the Delta Lake change data feed, Hudi incremental and CDC queries, and Iceberg incremental reads of appended data
Do several writers commit to one table?	Read how each handles conflicts: Iceberg writers retry, and a conflicting Delta Lake write fails
Which engines must read and write the table?	Check version and feature support in each project's docs for every engine you run
Must Iceberg clients read your Delta tables?	Delta Lake's Universal Format (UniForm) generates Iceberg metadata for that purpose

How does Databricks approach table formats?

Databricks documents that Delta Lake is the default format for all operations on Databricks. Unity Catalog also supports Iceberg. Iceberg tables you create in Unity Catalog are managed Iceberg tables (Databricks Runtime 16.4 LTS or above, with serverless compute for metadata maintenance), and Unity Catalog manages snapshot expiration and file compaction on them. Iceberg tables managed by another catalog are foreign Iceberg tables, which are read-only in Databricks.
In the other direction, Iceberg reads (UniForm) configure a Delta Lake table to generate Iceberg metadata, so Iceberg clients can read it without rewriting files (Databricks Runtime 14.3 LTS and above). External Iceberg engines can access Iceberg tables in Unity Catalog through the Iceberg REST Catalog API.

FAQs

Do all three provide transactions?

Each project documents them. Delta Lake "provides ACID transaction guarantees between reads and writes". Iceberg offers serializable isolation, where "table changes are atomic". Hudi lists transactions and concurrency control among its core database functionality.

Can I convert between formats?

With project tooling, yes. CONVERT TO DELTA parquet.`<path-to-table>` converts a Parquet table to Delta Lake in place by creating a transaction log that tracks the existing files. Iceberg's iceberg-delta-lake module offers a snapshotDeltaLakeTable action that builds an Iceberg table from a Delta Lake table's transactions and leaves the original Delta table unchanged. The Delta Lake docs say UniForm generates Iceberg metadata so Iceberg clients can read Delta tables.

Which format performs best?

This page makes no performance claims. Results depend on the engine, table layout and maintenance, so run the same workload on each candidate with the same data.

Does a table format lock me into one engine?

Each project's docs list several engines, including Apache Spark, Apache Flink and Apache Hive. Check the connector version for each engine you run.