Apache Hudi vs Apache Iceberg Performance: What Benchmarks Show, and What We Measured

If you searched "Hudi vs Iceberg performance benchmark" hoping for a single number, here is the honest answer: no single published benchmark settles the question, because results depend overwhelmingly on workload shape (append-only scans versus update-heavy ingestion), on configuration parity between the systems, and on the versions tested. What the record does show consistently is that on read-dominated benchmarks like TPC-DS, table-format overheads converge to within noise of each other once the formats are configured comparably, while on mutation-heavy workloads the write-path machinery — indexes, merge-on-read design, delete handling — dominates the cost curve and produces genuinely different results.

This post is written from a Hudi maintainer's seat, so let us be direct about the design-level conclusion we hold: for incremental, update-heavy writes, we believe Hudi will give you the best write performance of the major open table formats. Its record-level indexing and merge-on-read design bound write cost to the size of the change rather than the size of the table, and its concurrency model blocks writers less when table services run alongside ingestion — a real advantage if you are writing frequently. For scan-heavy queries and append-only writes, expect the formats to perform similarly. The rest of this post backs that up two ways: an inventory of the published benchmarks — what each measured, on which versions, with what methodology and limits — and incremental-write results from our own runs on current versions, using an open-source harness you can rerun yourself. Through it all, the strongest advice is the boring one: benchmark your own workload before you decide.

Why Lakehouse Benchmarks Are Hard to Get Right

Table-format benchmarks are unusually easy to get wrong, and the failure modes recur so reliably that they are worth naming up front.

Configuration parity is almost never achieved. The formats ship with different defaults because they optimize for different things. Hudi's default write operation is upsert, which pays for index lookups and record merging so mutations are cheap later; Iceberg and Delta default to append-style writes. Benchmark a bulk load on defaults and you are not measuring format efficiency — you are measuring whose defaults happen to match the workload. Vinoth Chandar's April 2022 "Corrections in data lakehouse table format comparisons" documented exactly this in an Oracle-published Hudi vs Delta comparison: the Hudi side ran GZip compression while Delta ran the faster Snappy, the load used upsert where bulk_insert was the documented recommendation, and the whole exercise ran on 100MB–1GB datasets too small to generalize from. The same post catalogued factual errors that had circulated in other published comparisons — claims that Hudi lacked deletes (the "D" in the original "Hadoop Upserts, Deletes and Incrementals" acronym), lacked PySpark support, or had a closed log format — all inaccurate when published. The lesson is not that anyone was uniquely careless; it is that cross-system comparisons are hard to get right even in good faith.

Default-versus-tuned is an editorial choice, not a neutral one. Out of the box, Hudi turns on table services and indexing that cost something at write time and pay off at read and update time. A benchmark that measures only the write pays the cost and never collects the payoff. Whether the right comparison is "both on defaults" or "both tuned by experts" is a judgment call — a credible benchmark states which it made and why.

Versions age fast. Every benchmark below names specific versions — Hudi 0.11, Hudi 0.14, Delta 1.2 — that have since been superseded by releases with materially different write paths (Hudi 1.x being the obvious example). A 2022 result is a historical data point, not a current one.

Provenance is context, not a verdict. Most published lakehouse benchmarks — including the ones in this post — come from people close to one of the projects, because the people motivated to measure a system are usually the people building on it. That is normal; it just means reproducibility is the thing to check. Published code, configs, versions, and hardware let you verify a result instead of taking it on trust, and that standard applies to our numbers below as much as anyone else's.

What TPC-DS-Style Benchmarks Show

TPC-DS is a decision-support benchmark: load the data once, then run about a hundred analytical queries. It is scan- and query-dominated, which means it exercises the part of a table format where the formats are most alike — listing files, pruning with statistics, and reading Parquet.

The most instructive public episode is from mid-2022. A benchmark by Databeans, shown during a Databricks keynote, reported Hudi dramatically slower than Delta and Iceberg on TPC-DS. Onehouse's June 2022 response, "Transparent TPC-DS Lakehouse Performance Benchmarks" by Alexey Kudinkin, re-ran the comparison on EMR 6.6.0 with Spark 3.2.0, testing Hudi 0.11.1 against Delta 1.2.0 and 2.0.0rc1 — with the configuration fixed for parity: Hudi switched from upsert to the documented bulk_insert for the one-time load, Parquet file-size settings matched to Delta's, metadata features unnecessary for the snapshot-query test disabled, and Spark dynamic allocation turned off to remove cluster-scaling noise. The corrected result, as of those mid-2022 versions: load performance within 6% between Hudi 0.11.1 and Delta, and "practically no difference" in query performance. Crucially, the modifications to the benchmarking framework were published so anyone could reproduce the run.

That episode is dated — those version numbers are ancient now — but its structural finding has held: on read-heavy TPC-DS-style workloads, comparably configured table formats land within noise of each other, because the query engine and the Parquet scan dominate, not the table metadata layer. Kyle Weller's 2023 compilation (next section) reached the same conclusion across multiple 2022 TPC-DS runs, noting that Iceberg trailed in those particular tests while Hudi and Delta were comparable — again on 2022 versions, and again with the caveat that TPC-DS never stresses the machinery where these projects actually differ.

If TPC-DS is your workload — append-only loads, heavy analytical scans — the published evidence says the format choice is unlikely to be your performance bottleneck, and you should weigh operational and ecosystem factors instead.

What Mutation-Heavy Comparisons Show

The picture inverts once the workload mutates data continuously, because now the write path — how a format finds the records to update, absorbs deletes, and amortizes merge costs — is the whole game, and here the formats differ architecturally rather than cosmetically.

The public record on this side is thinner but pointed. Kyle Weller's August 2023 "Delta, Hudi, Iceberg — A Benchmark Compilation" recounts a Walmart Global Tech evaluation on two real production scenarios rather than synthetic queries: a late-arriving-data workload with heavy read/write amplification, and row-level upserts fed by CDC from Cassandra. In Walmart's runs (on the then-current, now-old versions they tested), Delta struggled with background compaction, Iceberg failed to complete the write workloads, and Hudi handled both and was fastest. Treat that with the same discipline as every other result here: one team, one point in time, versions long since superseded — Iceberg's delete handling and compaction tooling have evolved since. But it illustrates the structural point: mutation-heavy workloads produce order-of-magnitude differences and outright failures where TPC-DS produces 5% differences.

Why the divergence? Mechanism. To update a record, a writer must first find it. Hudi ships a multi-modal indexing subsystem for exactly this, and the impact of index choice alone is measurable: Soumil Shah's October 2023 upsert evaluation on Hudi 0.14 with Spark 3.4.1 measured the same upsert workload under three of Hudi's global index options: 550 seconds with the global bloom index, 403 with the global simple index, and 301 with the record-level index — the record-level index roughly 45% faster than global bloom in his test. That is a Hudi-versus-Hudi number, not a Hudi-versus-Iceberg number, and that is precisely why it matters here: if index selection within one format moves upsert cost by 1.8x, a cross-format benchmark that does not state which index (or, for Iceberg, which delete strategy — copy-on-write, position deletes, or equality deletes) it used is not measuring what it claims. Merge-on-read design compounds this: how a format defers and amortizes merge work determines both write latency and the compaction bill that arrives later, and a benchmark that stops the clock before compaction has quietly excluded part of the cost.

The Benchmark Landscape, Compiled

Weller's 2023 compilation remains the best single map of the public record. In brief, the entries and their provenance:

• Databeans TPC-DS (June 2022), surfaced at a Databricks keynote; showed Hudi far behind. Corrected by Onehouse for the configuration issues described above; corrected results showed Hudi and Delta comparable, Iceberg trailing on those versions.
• Brooklyn Data TPC-DS (2022), commissioned by Databricks covering Delta and Iceberg; Onehouse extended it with Hudi. Same pattern on 2022 versions: Hudi and Delta comparable, Iceberg slower in that run.
• Microsoft LST-Bench (paper published May 2023), a research effort notable for methodology rather than a scoreboard: it extends TPC-DS with mutations, concurrency, and maintenance phases, and proposes longevity metrics — a direct acknowledgment that load-then-query benchmarks miss what matters for these systems.
• Walmart Global Tech's production-scenario evaluation, described above — the clearest published mutation-heavy comparison, and the one whose results diverge most sharply from the TPC-DS consensus.

Where the results conflict — Iceberg competitive-to-trailing on scans in some runs, not completing Walmart's write workloads — the conflict itself is the finding: the benchmarks were measuring different mechanisms. Weller's own bottom line is that performance benchmarks rarely represent real-life workloads and users should run their own. We agree, and we took that advice ourselves.

What We Measured Ourselves: Incremental Writes with LakeLoader

The biggest gap in the public record is mutation-heavy data on current versions, so we ran our own comparison. All workloads used LakeLoader, an open-source, format-agnostic benchmarking framework that generates parameterized change streams (scale, skew, update/insert mix) and applies identical rounds of changes to each table format — the workload definition is shared across systems, so differences in results come from the format's write path, not the harness. Setup: Apache Spark 3.5 on Amazon EKS with Amazon S3 storage, identical cluster configurations within each workload, testing Hudi 1.1.1, Iceberg 1.10.0, and Delta Lake 3.3.2. We measured steady-state incremental commit latency, excluding each system's initial-load and index-bootstrap commits.

In our runs, we observed:

Workload	What it models	What we observed
FACT, 10 TB, partitioned, skewed updates (Zipfian, 90% updates / 10% inserts)	Time-partitioned fact tables (events, transactions) with late-arriving updates	Hudi averaged ~4x lower incremental write latency than Iceberg and ~6x lower than Delta Lake
Merge-on-read, wide 100-column table, sparse partial updates (~20% of columns per update)	Dimension tables — user profiles, account masters — where updates touch a few columns	Hudi averaged ~8x lower steady-state latency than Iceberg and ~5x lower than Delta Lake, by appending only column-level deltas
Merge-on-read ingestion with concurrent async compaction	Streaming/CDC pipelines with background maintenance under ingestion SLAs	Hudi sustained continuous ingestion throughout; Iceberg and Delta Lake writes hit snapshot-conflict retries during compaction windows

The mechanism behind the FACT numbers is the one this post keeps returning to: Hudi's record-level index resolves which file groups each batch touches directly, so per-commit shuffle stays on the order of the incremental input (hundreds of megabytes in these runs), while the join-based tagging paths in the other two formats scanned and shuffled hundreds of gigabytes of the target table per commit. That is the same write-path architecture difference the Walmart evaluation surfaced in 2023 — now visible on current versions, with a published harness.

Apply the same discipline to these numbers that this post asks of every other benchmark. They are specific to these versions, this cluster shape, and these workload parameters, and they say nothing about scan-heavy or append-only workloads, where we expect the formats to land close together. The difference is that you do not have to take our word for anything: the workload definitions and run parameters live in LakeLoader, and you can rerun these workloads yourself on your own hardware, against whichever versions and configurations match your environment.

How to Run a Benchmark That Actually Means Something

The evergreen part of this post. If you benchmark Hudi against Iceberg for a real decision, the published record suggests this checklist:

1. Benchmark your workload shape, not TPC-DS. If your tables mutate, your benchmark must mutate — run sustained upsert/delete phases against a loaded table, not just the initial load.
2. Enforce configuration parity. Same compression codec, same target file sizes, same Spark/engine version and cluster. Use each format's documented recommendation for the operation at hand (e.g., Hudi bulk_insert for one-time loads, upsert for mutation phases).
3. State the index and delete strategy. For Hudi, which index; for Iceberg, copy-on-write vs merge-on-read and the delete-file mode. These are the largest levers on the write path.
4. Include table-service costs. Run compaction, clustering, and cleaning inside the measured window — or report them separately — for both systems. A write time that excludes the compaction it necessitates is fiction.
5. Separate cold and warm runs, and run queries during and after ingestion, not only on a freshly optimized table.
6. Measure over time, not one pass. The LST-Bench insight: performance after 100 commits differs from performance after one.
7. Publish versions, configs, and code. If you cannot reproduce it, neither can anyone who disagrees with it.

Questions to Ask of Any Published Benchmark

The recurring gaps above explain most of the disagreement between published results, so check for them systematically — in our numbers as much as anyone else's. Were both systems given documented, workload-appropriate configurations, or defaults for one and tuning for the other? Are versions stated, and were they current at publication? Does a "write performance" test include a sustained mutation phase, or only the initial load? Does the measured window include the compaction the writes necessitate? Is the dataset large enough to be representative? Are code and configs published so the run can be reproduced? Are multiple rounds reported, or a single pass? A benchmark can be run in good faith and still miss on one of these — but the more of them it misses, the less it can tell you about your workload.

The Honest Bottom Line

Choose by workload mechanism fit, then validate with your own benchmark. If your workload is append-mostly analytics, the published record says format overheads converge and your decision should rest on ecosystem, catalogs, and operations. If it is mutation-heavy — CDC, streaming upserts, deletes at scale — the write-path architecture differs materially, and the published record, the design analysis, and our own reproducible runs all point the same way: Hudi's indexed write path and non-blocking concurrency give it a real edge when you are writing frequently. See the mechanism-level companion posts on Hudi vs Iceberg for CDC workloads and Hudi vs Iceberg for streaming ingestion. Weigh the operational model too: Hudi ships its table services and indexing built in, while Iceberg leaves maintenance to engines and external tooling — a difference that shows up in benchmarks only when someone remembers to measure it.

One more option the 2022-era benchmark wars did not have: you no longer have to choose blind. Apache XTable (incubating) translates table metadata between Hudi and Iceberg without rewriting data files, so you can write with one format and expose the other — or A/B both against the same data — as described in our XTable interoperability post.

Conclusion

The published Hudi-versus-Iceberg record is smaller and older than the volume of opinion written on top of it. What it supports: read-heavy benchmarks show comparably configured formats within noise of each other (Onehouse, 2022, on 2022 versions); mutation-heavy evaluations show large, mechanism-driven differences favoring purpose-built write paths (Walmart via Weller, 2023, on the versions then tested); configuration parity gaps have distorted results in both directions (Chandar, 2022); and index or delete-strategy choice within a single format can swing results more than the format choice itself (Shah, 2023). Our own LakeLoader runs on current versions land where the design analysis predicts: for incremental, update-heavy writes, we are confident Hudi is the strongest choice — and the workloads are open for anyone to rerun. What no benchmark supports is a single number that settles the question for every workload. The number that should settle it for yours is the one you measure — so run yours.

FAQ

Is Apache Hudi faster than Apache Iceberg?

For incremental, update-heavy writes — CDC, streaming upserts, mutable tables — yes in our reproducible runs: LakeLoader benchmarks on Spark 3.5 testing Hudi 1.1.1 against Iceberg 1.10.0 measured roughly 4x lower incremental write latency for Hudi on a 10 TB skewed fact-table workload, driven by Hudi's record-level index avoiding full-table-scan joins, with larger gaps on merge-on-read tables with sparse column-level updates. For scan-heavy, append-only workloads, published TPC-DS-style results show comparably configured formats performing within noise of each other. The LakeLoader workloads are open source, so you can validate on your own hardware and workload shape.

Why do Hudi vs Iceberg benchmark results disagree so much?

Because they measure different things under different conditions. Scan-heavy benchmarks exercise the layer where the formats are most alike, while update-heavy benchmarks exercise indexing, merge-on-read, and delete handling, where they differ architecturally. Configuration disparities, such as mismatched compression codecs or using Hudi's upsert where bulk_insert is recommended, have also skewed published results, and every result is tied to the specific versions tested, which age quickly.

What is the best benchmark for comparing table formats?

One that matches your workload shape and is reproducible. TPC-DS alone is a poor fit because it never mutates data after loading; Microsoft's LST-Bench (2023) improves on it by adding mutation, concurrency, and maintenance phases, and the open-source LakeLoader framework applies identical parameterized change streams to each format for incremental-write comparisons. The most meaningful test is your own pipeline replayed against both formats with identical file sizes, compression, engine versions, and table-service costs included.

Do Hudi's indexes really change upsert performance that much?

Yes, measurably. Soumil Shah's October 2023 evaluation on Hudi 0.14 found the record-level index roughly 45% faster than the global bloom index and about 25% faster than the global simple index on the same upsert workload. That within-format spread is why cross-format benchmarks that do not state their index or delete-strategy configuration are hard to interpret meaningfully.

Can I test both formats without maintaining two copies of my data?

Yes. Apache XTable (incubating) translates table metadata between Hudi and Iceberg without rewriting the underlying data files, so you can write with one format and query through the other, or run comparative tests against the same physical data. That makes the format decision testable rather than a leap of faith.