Pick a vendor blog and you’ll find a feature matrix comparing Iceberg, Delta Lake, and Hudi across thirty rows. Pick another and the rows are different. Pick a third and the winner has flipped. The matrix is decorative for most readers because the differences it surfaces are not the ones that bind a particular workload to a particular format. Knowing where the choice is load-bearing — and where you could swap formats without anyone noticing — is the only useful framing.
The honest version: for the median analytics workload, all three work. The places where they meaningfully diverge are narrow, but when you land in one of them, the cost of choosing wrong is high enough that the matrix-shopping was worth it after all. The trick is recognizing which side of that line you’re on before you commit.
Where the choice is decorative
Batch ELT into a single warehouse-style consumer. If your write pattern is “Spark or dbt-on-Trino lands daily partitions, downstream BI reads the latest snapshot,” any of the three handles it. The schema evolution stories differ in detail but converge in practice. Snapshot isolation works. Partition pruning works. Time travel works. You will not feel the difference between Iceberg and Delta on this workload because the workload is not exercising the parts that differ.
Single-engine shops. If 95% of your reads and writes flow through one compute engine, the format’s portability story is theoretical. Delta on Databricks, Iceberg on Snowflake, Iceberg on AWS-native stacks — pick whichever the vendor you’ve already committed to optimizes hardest. The “you can swap engines later” pitch is real but rarely exercised; meanwhile the engine you’re on now ships features against its preferred format faster.
Greenfield analytics with no streaming. Hudi’s reason to exist is upserts and CDC at write time. If your pipelines are append-only or full-refresh, you’re paying Hudi’s complexity tax without using what it bought you. Iceberg or Delta will be calmer.
Where the choice is load-bearing
Streaming upserts and mutable rows. Hudi was built for this and still does it best. Merge-on-read tables, record-level indexing, async compaction tuned for write-heavy workloads — these aren’t features you can replicate by squinting at Iceberg’s row-level operations API. If your workload is “thousands of CDC mutations per second landing in queryable tables,” Hudi remains the answer despite the operational tax. Iceberg’s v3 spec narrows the gap; it does not close it for high-frequency mutation patterns.
True multi-engine, multi-vendor freedom. Iceberg has won the catalog interoperability war. The REST catalog spec is implemented or being implemented by Snowflake, AWS, Databricks (alongside Unity), Dremio, Tabular’s successors, and the long tail. If your strategy depends on the table being readable and writable by engines from competing vendors next year and the year after, Iceberg is the format whose neutrality is structural rather than aspirational. Delta’s openness is real but its center of gravity is Databricks; Hudi’s multi-engine story exists but the integrations are uneven.
Databricks-native shops with no exit ambition. Delta on Unity Catalog with Photon and predictive optimization is genuinely faster on Databricks than Iceberg-on-Databricks. The optimization path Databricks ships against Delta is not coming to Iceberg with the same urgency. If you are committed to Databricks and your workload is performance-sensitive, Delta is the right answer; pretending otherwise to preserve a portability option you’ll never exercise is a tax for nothing.
Time-travel and audit as a product requirement. All three support snapshot isolation. Iceberg’s snapshot-and-branch model is the most ergonomic if you need to expose time travel as a user-facing feature — reproducible ML training datasets, regulatory point-in-time queries, branch-based dev environments against production tables. Delta has the equivalents; the API surface is heavier. Hudi’s timeline model is powerful but oriented toward write-side concerns, not read-side reproducibility.
How to tell which side you’re on
Three honest questions, answered without optimism.
First: how many distinct compute engines will write to these tables in the next eighteen months? If the answer is one, the multi-engine pitch is decorative. If the answer is three or more from different vendors, Iceberg’s catalog neutrality is load-bearing.
Second: what is the dominant write pattern? Append-and-overwrite is format-agnostic. Per-record upserts at streaming volume is Hudi’s home turf and the others’ weakest mode.
Third: what is the actual cost of being wrong? Switching formats later is painful but not impossible — most large-table migrations land in the days-to-weeks range, not months. If your workload is in the decorative zone, optimize for whatever ships fastest with your current vendor and reserve the architectural energy for problems that actually move revenue.
The matrix-shopping is fine. Just know which rows in the matrix you’re actually buying.