TL;DR — Direct Answer
Stop comparing feature matrices — the three formats converged on features years ago. Decide on four axes: (1) Query engines: Databricks-centric → Delta; multi-engine (Spark + Trino + warehouse externals) → Iceberg. (2) Write pattern: streaming upserts/CDC-heavy → Hudi still earns its complexity; append-mostly → Delta or Iceberg. (3) Team size: small teams should pick whatever their primary platform manages for them. (4) Cloud/vendor posture: maximum neutrality → Iceberg, which has become the industry's default interchange format. When in doubt in 2026: Iceberg.
Why feature comparisons mislead
ACID, time travel, schema evolution, hidden/partition evolution, merge-on-read — all three formats check all the boxes now. Articles comparing checkboxes answer the question of 2021. The 2026 question is which ecosystem are you marrying, because the format determines which engines read your tables natively, which vendor's optimizer compacts them, and who you call when metadata corrupts at 2 a.m.
The four decision axes
Axis 1 — Query engines (weight: highest)
List every engine that must read or write the tables in the next three years: Spark, Trino/Presto, Flink, BigQuery, Snowflake, Redshift Spectrum, DuckDB, Dremio. Delta is first-class on Databricks and good in OSS Spark; external-engine support exists but trails. Iceberg has native read/write across effectively every engine, including external-table support in Snowflake and BigQuery — which is why it won the interchange war. Hudi reads fine from Spark/Trino but has the thinnest third-party surface.
Axis 2 — Write pattern
Append-dominant (events, logs, immutable facts): all three work; choose by Axis 1. Update-heavy CDC mirroring with record-level upserts and incremental consumption: Hudi was built for exactly this and its merge-on-read tables still handle high-frequency upserts with the least tuning. Delta and Iceberg both do MERGE fine at moderate frequency — but sustained minute-level upserts at scale need careful compaction design on either.
Axis 3 — Team capacity
Table formats need maintenance: compaction, snapshot expiry, orphan-file cleanup, manifest optimization. Databricks does this for Delta automatically (OPTIMIZE, auto-compaction, VACUUM). Iceberg increasingly gets it managed via catalogs (Glue, Polaris, Tabular-lineage services). Self-managed Hudi gives you the most knobs and demands the most attention. A two-engineer team should buy managed maintenance, whatever the logo.
Axis 4 — Vendor posture
If contract leverage and exit options matter to your CFO, Iceberg's engine-neutrality is itself the feature. If you are strategically committed to Databricks, Delta's deep integration (and Databricks' own Iceberg interoperability via UniForm) means you lose little either way.
The decision tree
- Databricks is your primary platform → Delta (enable UniForm if externals must read it).
- Multiple engines, warehouse external tables, or vendor-neutrality mandate → Iceberg.
- CDC-mirroring dozens of OLTP tables with sub-15-minute upserts, and you own the ops → Hudi.
- Small team, no strong platform commitment yet → Iceberg on a managed catalog, revisit in two years.
Five scenarios, called honestly
| Scenario | Our call | Why |
|---|---|---|
| Databricks shop, BI + ML | Delta | Native optimization, zero friction; UniForm covers externals |
| GCP + BigQuery, Spark for ML | Iceberg | BigLake/BigQuery Iceberg externals; engine neutrality |
| Bank mirroring 200 OLTP tables via CDC | Hudi (or Delta on Databricks) | Record-level upserts + incremental pulls are the core need |
| Startup, 2 data engineers, AWS | Iceberg + Glue catalog + Athena | Serverless reads, managed metadata, no cluster to babysit |
| Multi-cloud enterprise, anti-lock-in mandate | Iceberg | It is the interchange standard; everything reads it |
Migration reality check: converting formats later is possible (metadata-level converters exist) but re-tuning compaction, rewriting maintenance jobs, and re-validating downstream is a quarter of engineering. Choose deliberately the first time — this is the framework we use in our warehousing engagements.