Apache Iceberg vs Delta Lake vs Apache Hudi

Which format to choose by workload

This table maps common lakehouse workloads to the table format that fits each best, with the supplied facts behind each choice and the condition that would point elsewhere. Read it by matching your dominant workload to a row, then checking the condition column against your engines, catalog and write pattern. The main takeaway is that engine mix and write pattern decide the format more than feature lists do.

How each format tracks snapshots, deletes and updates

Capabilities of Iceberg, Delta Lake and Hudi side by side

This table compares governance, licensing, release status, schema and time travel, update and delete handling, streaming ingestion, catalogs, engine support and cross-format reads for the three open table formats. Where a capability is not covered by the supplied project facts, the cell says what to confirm in the project documentation. Use it to narrow the shortlist, then test the rows that decide your workload against your own engines.

License and governance of each format

What drives the running cost of each format

Licenses for all three formats are open source, so the running cost sits mostly in the platform around the table. The cards below separate one-time work such as migration and schema design from recurring spend on compute, storage, catalog operations and the people who keep the tables healthy.

What implementing each format involves

How to move between formats without a full rewrite

This sequence turns a format decision into a staged move, so each table changes only after engines, catalog and compatibility have been checked. The result is a documented cutover plan that tells you what is safe to migrate and what still needs a decision.

1. Inventory engines and write patterns

   Your data platform team lists every engine that reads or writes lakehouse tables, such as Spark, Trino, Flink or Presto, and records the write pattern for each table: append-only loads, batch merges, row-level updates and deletes, or streaming upserts with change data capture. Engine versions and the connector each one uses go on the same list. This matters because Iceberg, Delta Lake and Hudi differ most on how updates, deletes and streaming writes are handled, so the write pattern drives the shortlist. The step is done when every engine and table has a named owner and a documented write pattern, and the team agrees which connectors each engine needs.

2. Map the current catalog and metastore

   Your platform team records which catalog holds table definitions today, such as a Hive metastore, AWS Glue, a REST catalog or a vendor-managed catalog, and which engines depend on it. Trino's Iceberg connector supports several catalog types set through iceberg.catalog.type, so the catalog choice can limit which engines can see a table. The owner of the catalog confirms how it handles access control and lineage for each format. The step is complete when the team can state which catalog every table lives in, which engines read through it, and which catalog options each candidate format supports in your environment, confirmed with the vendor or project documentation.

3. Pilot one representative table

   Choose one table that represents the common write pattern, is read by at least two engines, and carries modest business risk. The data engineering team creates a copy in the candidate format, loads it from the same source, and runs the agreed queries and writes. They check row counts, schema behavior, partitioning and any time travel or rollback needs your auditors or analysts rely on. The pilot is done when the copy matches the source for the agreed queries and the team has written down every engine that needed extra configuration or a connector that was in preview.

4. Test compatibility with UniForm or engine connectors

   Where the target format is the one already in use, you can test cross-format reads before moving any data. Delta.io describes UniForm (Delta Universal Format) as a way for Iceberg and Hudi clients to read Delta tables, so a platform team can confirm which readers see the pilot table correctly. Where a connector is needed instead, the team tests the Trino or Flink connector against the pilot and records whether it is documented as preview or production. Engineers confirm read results, write permissions and metadata refresh behavior for each reader. The step closes with a compatibility matrix that lists each engine, format, connector and known gap, with the test evidence attached.

5. Decide the catalog and governance model

   The architecture group chooses the catalog that will hold tables after cutover, weighing which engines it serves, how it handles access control, and who operates it. This decision also sets who owns table definitions, retention, and the audit trail. Migration cost depends heavily on this choice, because a catalog change touches every table and every engine that reads it. The group signs off a written decision record that names the catalog, its operator, its access model and the formats it supports. The step is complete when the record is approved and each pilot engine has been tested against the chosen catalog.

6. Plan tables in waves

   Platform owners group the remaining tables by write pattern, engine dependency and downstream consumers, then schedule them in waves. Low-risk, read-mostly tables go first. Tables with streaming writes, change data capture or heavy row-level deletes move later, once the team has proven the chosen write path on the pilot. Each wave has a rollback point, usually keeping the source table readable until the consumers confirm results. The cost of switching later grows with the number of tables and engines, so the plan should record the count of each for every wave. The plan is done when every table has a wave, an owner and a rollback method.

7. Run cutover with reconciliation and rollback

   For each wave, the data team freezes writes or stages a short window, runs the final load into the target format, and reconciles row counts, key checks and sample queries against the source. Downstream owners confirm their reports and jobs read the new table. The team keeps the source readable until the agreed reconciliation passes, then retires it according to the retention policy. Each cutover ends with a signed reconciliation report and a documented rollback path. The step is complete when every wave has a signed report and the old tables are either archived or removed under the approved retention rules.

Questions buyers ask before choosing a table format