The data lakehouse has a winner-take-most fight at its core, and in 2026 that fight is finally resolving. Three open table formats – Apache Iceberg, Delta Lake, and Apache Hudi – turn cheap object storage full of Parquet files into something that behaves like a database, complete with ACID transactions, schema evolution, and time travel. Pick the right one and you decouple your data from any single vendor’s compute engine. Pick the wrong one and you can spend years untangling proprietary metadata.
This comparison puts Apache Iceberg vs Delta Lake vs Hudi head-to-head with current data: GitHub momentum, the Apache Iceberg v3 specification that reached general availability in mid-2026, Delta Lake 4.0’s engine-independence push, Apache Hudi 1.x’s streaming engine, the multi-billion-dollar acquisitions reshaping the market, and the catalog war that now matters more than the file layout itself. By the end you will know exactly which format fits a Databricks shop, an AWS-native analytics stack, or a streaming-first ingestion pipeline – and how to move between them when you change your mind.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Open Table Formats Actually Solve
To understand the iceberg vs delta lake debate, start with the problem all three formats were built to fix. A data lake is, at its simplest, a pile of columnar files – usually Apache Parquet, sometimes ORC or Avro – sitting in object storage like Amazon S3, Azure Data Lake Storage, or Google Cloud Storage. That is wonderfully cheap and infinitely scalable, but a directory of Parquet files is not a table. It has no transaction boundary, so two writers can corrupt each other’s output. It has no atomic commit, so a failed job can leave half-written data. It cannot rename a column without rewriting everything, and it certainly cannot tell you what the data looked like last Tuesday.
An open table format is a metadata layer that sits on top of those data files and adds database semantics without a database. It tracks which files belong to a table at any given moment, records every change as an atomic snapshot, and exposes that history to query engines through a well-defined specification. The result is ACID transactions on a data lake – the “lakehouse” pattern that merges the cheap storage of a lake with the reliability of a warehouse. Crucially, because the specification is open and the data stays in standard Parquet, any compliant engine can read the same table. That is the entire promise: store once, query with Spark, Trino, Flink, Snowflake, BigQuery, DuckDB, or ClickHouse, and never pay an export tax to switch.
All three formats deliver this core feature set: atomic commits, snapshot isolation, schema evolution, time travel to prior table states, and row-level updates and deletes. Where they diverge is philosophy. Iceberg was designed as a vendor-neutral specification first and an implementation second. Delta Lake grew out of Apache Spark and optimized for that engine before broadening out. Hudi was engineered around a single hard problem – fast, incremental upserts on streaming data – and everything else followed from that. Those origin stories still shape which workloads each format wins today.
Apache Iceberg vs Delta Lake vs Hudi: Specs at a Glance
The table below captures the state of all three projects as of mid-2026, with version numbers and star counts pulled directly from each project’s GitHub repository. Apache Iceberg’s cadence is the fastest of the three: the Apache Software Foundation shipped 1.11.0 on 15 May 2026 as the current release, barely two days after patching the prior line with 1.10.2 on 13 May 2026. Treat star counts as a rough popularity signal rather than a quality verdict – but the trend lines are telling, and Iceberg’s late surge mirrors its adoption by every major cloud vendor.
| Attribute | Apache Iceberg | Delta Lake | Apache Hudi |
|---|---|---|---|
| Created by | Netflix (Ryan Blue, Dan Weeks) | Databricks | Uber |
| First released | 2017â2018 | 2019 | 2016 (OSS 2017) |
| Governance | Apache Software Foundation | Linux Foundation | Apache Software Foundation |
| Latest version (Jun 2026) | 1.11.0 (May 20, 2026) | 4.3.0 (Jun 18, 2026) | 1.2.0 (May 23, 2026) |
| GitHub stars | ~8,997 | ~8,886 | ~6,181 |
| License | Apache-2.0 | Apache-2.0 | Apache-2.0 |
| Data file formats | Parquet, ORC, Avro | Parquet | Parquet, ORC, HFile |
| Metadata model | Snapshot metadata tree + manifests | Transaction log (_delta_log) | Timeline + LSM-tree |
| ACID transactions | Yes | Yes | Yes |
| Schema evolution | Full (add/drop/rename/reorder) | Full | Full |
| Partition evolution | Yes (in-place) | Liquid Clustering | Limited |
| Hidden partitioning | Yes | No (clustering instead) | No |
| Time travel | Yes (snapshot/timestamp) | Yes (version/timestamp) | Yes (commit instant) |
| Row-level deletes | Deletion vectors (v3) | Deletion vectors | MOR delta logs |
| Upserts / CDC | MERGE | MERGE | Native upsert + CDC |
| Streaming ingestion | Flink, Spark | Spark Structured Streaming | Streaming-first (DeltaStreamer) |
| Concurrency control | Optimistic | Optimistic + Coordinated Commits | OCC + Non-Blocking (NBCC) |
| Catalog options | REST, Polaris, Glue, Nessie, Hive | Unity Catalog, Hive metastore | Hive metastore, Glue |
| Primary backers | AWS, Snowflake, Google, Cloudera | Databricks, Microsoft | Onehouse, AWS EMR, Uber |
| Sweet spot | Open, multi-engine analytics | Databricks & Microsoft Fabric | Streaming upserts & CDC |
Two things jump out. First, all three are permissively licensed Apache-2.0 projects – the format itself costs nothing, a point we will return to in the pricing section. Second, the convergence is real: features that once distinguished one format (deletion vectors, variant types, broad engine support) are arriving in all three. The differences in 2026 are increasingly about ecosystem gravity and catalog strategy rather than raw capability.
Origins and Governance: Netflix, Databricks, and Uber
Each format carries the fingerprints of the company that built it. Apache Iceberg was created at Netflix by Ryan Blue and Dan Weeks to solve the pain of managing petabyte-scale tables on S3, where Hive’s directory-listing approach buckled under millions of files and slow, non-atomic partition operations. Iceberg’s answer was to track files explicitly in a metadata tree rather than inferring them from directory layout. It became a top-level Apache project in 2020 and was deliberately designed to be engine-agnostic – no single vendor owns the reference implementation, which is exactly why competing clouds were willing to standardize on it. That governance model shows up in the release cadence too: the Apache Software Foundation shipped three major core releases in 2025 alone, from the 1.8.1 bug-fix update on 24 February 2025 through 1.10.0 on 5 September 2025, each one landing through community vote rather than a single vendor’s roadmap.
Delta Lake emerged from Databricks in 2019 as the storage layer beneath its Spark platform. Its transaction log design is elegant and battle-tested, but for years Delta was effectively Spark-first, and the best features landed in Databricks’ proprietary runtime before reaching open source. Databricks has worked hard to change that perception, donating Delta to the Linux Foundation and, with Delta Lake 4.0, investing in a Delta Kernel that lets non-Spark engines read and write a single canonical implementation. The official Delta Lake 4.0 announcement frames this as the format’s largest update to date.
Apache Hudi – the name stands for “Hadoop Upserts Deletes and Incrementals” – was born at Uber in 2016 to ingest constantly-changing trip and rider data into the lake in near real time. While Iceberg and Delta started from the analyst’s perspective of large, mostly-append tables, Hudi started from the data engineer’s perspective of mutable streams that need record-level upserts and change data capture. That heritage makes Hudi the most database-like of the three, and Apache Hudi 1.0, which reached general availability in January 2025 per InfoQ’s coverage, leaned into that identity with secondary indexes and a redesigned timeline.
Architecture Deep Dive: Three Ways to Track a Table
The deepest technical differences in the delta lake vs hudi vs iceberg comparison come down to how each format records what belongs to a table and how it commits a change. These metadata designs determine planning speed, concurrency behavior, and how well each format scales to tables with millions of files.
Iceberg’s Snapshot Metadata Tree
Iceberg organizes metadata as a hierarchy: a catalog points to a current metadata file, which references a manifest list, which references manifest files, which finally list the data files and their column-level statistics. Every write produces a new immutable snapshot, and the catalog atomically swaps a pointer to make it current. Because file pruning happens by reading manifests rather than listing object-storage directories, query planning stays fast even on tables with millions of files. Hidden partitioning – where Iceberg stores the partition transform in metadata so users never write awkward partition predicates – is a direct consequence of this design. The full mechanics are documented in the Apache Iceberg table specification.
Delta Lake’s Transaction Log
Delta Lake records every change as an ordered series of JSON commit files in a _delta_log directory, periodically compacted into Parquet checkpoints for fast state reconstruction. Each commit lists the files added and removed, making the log the single source of truth for the table’s current state. This design is simple, robust, and easy to reason about, and it underpins Delta’s strong Spark Structured Streaming support. Delta Lake 4.0’s Coordinated Commits feature adds an optional commit coordinator so that multiple engines and clouds can write safely without relying on the filesystem’s rename semantics – a meaningful step toward true multi-engine writes.
Hudi’s Timeline and Indexes
Hudi tracks every action – commits, compactions, cleans – on a timeline, and Hudi 1.0 replaced the old flat timeline with a log-structured merge (LSM) tree for efficient long-term retention and faster planning on tables with billions of records. The defining feature is its indexing subsystem: a record-level index maps primary keys to file locations so Hudi can perform true upserts without scanning the whole table, and Hudi 1.0 added SQL-defined secondary indexes and expression indexes reminiscent of PostgreSQL. This is also where Hudi’s two table types matter: Copy-on-Write (COW) rewrites files on update for read-optimized tables, while Merge-on-Read (MOR) appends delta logs for write-optimized, high-frequency ingestion.
Apache Iceberg in 2026: v3, Deletion Vectors, and the de facto Standard
If 2024 was the year the industry chose Iceberg, 2026 is the year it cashed the check. The headline is the Apache Iceberg v3 specification, which reached general availability on Snowflake and entered public preview on Databricks Runtime 18 in April 2026. Getting there took a steady drumbeat of core releases through 2025 and into 2026: 1.9.0 landed 22 April 2025, was patched twice with 1.9.1 on 21 May 2025 and 1.9.2 on 4 July 2025, and the 1.10.x line followed with 1.10.0 on 5 September 2025 and a 1.10.1 maintenance update on 16 December 2025. After roughly four years of community development, v3 adds seven major capabilities: deletion vectors, row lineage, a VARIANT type for semi-structured data, default column values, native geometry and geography types, nanosecond-precision timestamps, and multi-argument partition transforms.
Deletion vectors are the standout. Instead of v2’s positional delete files, v3 stores deletes as compact binary bitmaps applied at O(1) per row, which the Databricks engineering team reports can be up to 10x faster than the v2 approach for merge-heavy workloads. Row lineage – now mandatory for newly created rows in v3 – gives engines a built-in way to track row-level changes, a foundation for cheaper incremental processing and change data capture. Snowflake’s own v3 announcement emphasizes the VARIANT type as the bridge between its long-standing semi-structured support and the open format.
The ecosystem moves explain Iceberg’s gravity better than any feature list. In June 2024, Databricks acquired Tabular – the company founded by Iceberg’s original Netflix creators – for a reported sum widely placed at over $1 billion, with some estimates reaching $2 billion. The same year, Amazon launched S3 Tables, the first S3 storage class with native Iceberg support, making Iceberg the default for Athena, Glue, and EMR; the feature set is detailed on the AWS S3 Tables page. Snowflake open-sourced its Polaris catalog and contributed it to the Apache foundation. When AWS, Snowflake, Google, and even Delta’s own creator Databricks all commit to reading and writing Iceberg, the network effect becomes self-reinforcing. Companies including Netflix, Apple, LinkedIn, and Adobe run Iceberg at massive scale. The ecosystem is also expanding beyond the JVM: the Apache Iceberg C++ subproject shipped its 0.2.0 release on 26 January 2026, following the initial 0.1.0 debut in September 2025, and the Apache Iceberg Rust project reached 0.10.0 in July 2026 after merging 254 pull requests from 40 contributors between March and July 2026 – evidence that native, non-JVM engines are becoming first-class citizens rather than an afterthought.
A minimal Iceberg table created through Spark SQL shows how unremarkable the day-to-day experience has become – which is exactly the point of a mature standard:
-- Create an Iceberg table via a Spark catalog
CREATE TABLE lake.analytics.events (
event_id BIGINT,
user_id BIGINT,
event_type STRING,
ts TIMESTAMP
)
USING iceberg
PARTITIONED BY (days(ts));
-- Time travel to a prior snapshot
SELECT count(*) FROM lake.analytics.events
FOR SYSTEM_VERSION AS OF 7180181820440158191;
-- Evolve the partition spec in place, no rewrite
ALTER TABLE lake.analytics.events
ADD PARTITION FIELD bucket(16, user_id);Delta Lake 4.0 in 2026: Liquid Clustering, Kernel, and Fabric
Delta Lake’s strategy in 2026 is to neutralize its biggest historical weakness – the perception that it is a Databricks-only format – while leaning on its biggest strength, a vast installed base inside Databricks and Microsoft Fabric. Delta Lake 4.0, released in late 2025 and now at 4.3.0, is the clearest expression of that plan. The marquee features are Liquid Clustering, the Open Variant type, Delta Kernel, Delta Connect, and Coordinated Commits.
Liquid Clustering replaces rigid Hive-style partitioning and Z-ordering with a flexible physical layout that adapts to high-cardinality keys like user or device IDs, and it automatically falls back to Z-order behavior when clustering on a single column. Delta Kernel is the strategic one: it provides a single core library so that non-Spark engines such as Trino and Flink align on one implementation instead of maintaining bespoke connectors that drift out of sync. Delta Connect extends Delta operations over the Spark Connect wire protocol, and Coordinated Commits enables safe multi-cloud, multi-engine writes by designating a commit coordinator rather than trusting filesystem rename atomicity.
Delta’s other ace is Microsoft Fabric. OneLake, Fabric’s unified storage layer, is Delta-native, which instantly makes Delta the default table format for a huge population of enterprise Microsoft customers. Combined with Databricks’ own ubiquity, that installed base means Delta is not going anywhere, even as Iceberg wins the open-standard argument. A typical Delta workflow with a MERGE upsert and clustering looks like this:
-- Create a Delta table with Liquid Clustering
CREATE TABLE main.sales.orders (
order_id BIGINT,
customer BIGINT,
amount DECIMAL(12,2),
updated_at TIMESTAMP
)
USING delta
CLUSTER BY (customer);
-- Upsert with MERGE
MERGE INTO main.sales.orders AS t
USING staged_orders AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;
-- Read a previous version
SELECT * FROM main.sales.orders VERSION AS OF 42;Apache Hudi 1.x in 2026: Streaming Upserts and Indexing
Hudi is the format most likely to be underrated in a casual iceberg vs delta lake framing, because its strengths only show up in workloads the other two were not designed for. Apache Hudi 1.0 (GA January 2025) and the subsequent 1.x line – now at 1.2.0 – repositioned Hudi as “a database experience on the data lake,” and the feature set backs up the slogan. The Hudi 1.0 release notes detail the changes.
The headline additions are a record-level index that keeps write latency low on large mutable datasets, a new secondary indexing system that supports SQL-defined and expression-based indexes to cut query scan costs, and Non-Blocking Concurrency Control (NBCC) that lets multiple writers commit to the same table concurrently without serializing behind a lock. Underneath, the LSM-tree timeline supports long retention and high-performance planning on tables with billions of records. For change data capture and streaming ingestion – Kafka into the lake, database replication, sensor data – Hudi’s Merge-on-Read tables absorb high-frequency updates with minimal write amplification, then compact in the background for fast reads.
Hudi’s challenge is mindshare and momentum, not engineering. With roughly 6,181 GitHub stars it trails Iceberg and Delta, and the hyperscaler endorsements have largely flowed to Iceberg. Onehouse, founded by Hudi creator Vinoth Chandar, provides the commercial managed service and has pushed Hudi’s universal-data-lakehouse message hard. If your problem is high-throughput upserts and incremental pipelines, Hudi remains the most purpose-built choice; if your problem is broad read analytics across many engines, the ecosystem pulls elsewhere.
# Apache Hudi upsert with Spark (Merge-on-Read)
hudi_options = {
"hoodie.table.name": "rides",
"hoodie.datasource.write.table.type": "MERGE_ON_READ",
"hoodie.datasource.write.recordkey.field": "ride_id",
"hoodie.datasource.write.precombine.field": "ts",
"hoodie.datasource.write.operation": "upsert",
"hoodie.metadata.record.index.enable": "true"
}
(df.write.format("hudi")
.options(**hudi_options)
.mode("append")
.save("s3://lake/rides"))Feature-by-Feature Comparison
Beyond the headline specs, the day-to-day differences between these formats live in how they handle updates, concurrency, and indexing. The matrix below scores the three on the capabilities that most often decide an architecture review, using a simple Strong / Good / Limited scale based on each project’s 2026 documentation and the widely cited Dremio comparison of data lake table formats.
| Capability | Iceberg | Delta Lake | Hudi |
|---|---|---|---|
| Read-heavy analytics | Strong | Strong | Good |
| Streaming upserts / CDC | Good | Good | Strong |
| Multi-engine portability | Strong | Good | Good |
| Partition evolution | Strong | Good (clustering) | Limited |
| Indexing for point lookups | Good | Good | Strong |
| Schema evolution | Strong | Strong | Strong |
| Concurrency for many writers | Good | Strong (coordinated) | Strong (NBCC) |
| Catalog ecosystem | Strong | Good | Limited |
| Cloud vendor support | Strong | Good | Limited |
| Semi-structured (VARIANT) | Strong (v3) | Strong (4.0) | Good |
Read the matrix as a fingerprint rather than a scoreboard. Iceberg’s strengths cluster around openness and analytics; Delta’s around concurrency and the Spark/Fabric ecosystem; Hudi’s around mutation-heavy, streaming workloads and indexing. No row is a knockout, and for many general-purpose tables you could choose any of the three and be productive. The decision sharpens only when your workload pushes hard on one axis.
Performance and Benchmarks: What the Numbers Really Say
Table-format benchmarks deserve a health warning before any number is quoted: nearly every public benchmark is published by a vendor with a stake in the outcome, and results swing wildly with workload, file sizing, compaction settings, and the engine doing the reading. Treat the figures below as directional, drawn from three differently-aligned sources, not as a leaderboard.
- Update/merge performance. The clearest verified figure comes from the Iceberg v3 deletion-vector work: replacing v2 positional deletes with binary bitmaps yields up to a 10x speedup on merge-heavy workloads, per Databricks’ v3 engineering write-up. Delta Lake’s own deletion vectors deliver a similar class of improvement for the same reason.
- Read-optimized analytics. Databricks’ LHBench, a TPC-DS-derived lakehouse benchmark, has historically shown Delta and Iceberg close on large scan-heavy queries, with Copy-on-Write layouts favoring reads. Because LHBench is Databricks-authored, independent reviewers caution against reading the absolute Delta margins literally.
- Write-heavy ingestion. Benchmarks published by Onehouse, the Hudi-backing vendor, consistently show Hudi’s Merge-on-Read tables leading on high-frequency upsert throughput and write latency, which aligns with Hudi’s design but again reflects the source’s alignment.
The defensible, vendor-neutral takeaways: deletion vectors have made row-level updates dramatically cheaper across both Iceberg and Delta in their latest specs; Copy-on-Write layouts (Iceberg, Delta, Hudi-COW) win read-dominated analytics; and Merge-on-Read layouts (Hudi-MOR) win write-dominated streaming ingestion at the cost of read-time merging. If a vendor quotes you a single percentage that “proves” one format is universally faster, ask which workload, which engine, and who paid for the benchmark.
Catalogs: The Real 2026 Battleground
Here is the plot twist that reframes the entire apache iceberg vs delta lake vs hudi conversation in 2026: the file format is increasingly settled, and the genuine competition has moved up a layer to the catalog. A catalog is the service that tracks which tables exist, enforces access control, and brokers atomic commits. Whoever owns the catalog owns governance, lineage, and ultimately the customer relationship – which is why every major vendor is now fighting over it.
The Iceberg REST Catalog specification has become the lingua franca, decoupling engines from any specific metastore implementation. Around it, a cluster of implementations now competes: Snowflake-originated Apache Polaris (incubating), Databricks’ Unity Catalog (open-sourced in 2024), AWS Glue Data Catalog, Dremio’s git-inspired Project Nessie, and Apache Gravitino as a unified metadata layer. The strategic irony is sharp: Databricks open-sourced Unity Catalog and added Iceberg REST support, while Snowflake gave Polaris to Apache – both racing to be the neutral catalog that everyone trusts, precisely because neutrality is what wins in an Iceberg world.
For practitioners, the practical advice is to choose a catalog that speaks the Iceberg REST protocol so you are not relocked at the governance layer after you carefully avoided lock-in at the storage layer. Delta and Hudi both anchor more tightly to specific catalogs today – Unity Catalog and the Hive metastore respectively – which is a quiet but real factor in long-term portability. Pointing an engine at a REST catalog is now a few lines of configuration:
# Spark config for an Iceberg REST catalog
spark.sql.catalog.lake = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.lake.type = rest
spark.sql.catalog.lake.uri = https://catalog.example.com/api
spark.sql.catalog.lake.warehouse = s3://lake/warehouse
spark.sql.catalog.lake.io-impl = org.apache.iceberg.aws.s3.S3FileIOEngine and Cloud Ecosystem Support
For most teams, the single most important question is brutally practical: which query engines and managed services can read my tables today, without a connector science project? This is where Iceberg’s lead is widest, and where the ecosystem table below tells the clearest story.
| Engine / Service | Iceberg | Delta Lake | Hudi |
|---|---|---|---|
| Apache Spark | Yes | Yes (native) | Yes |
| Apache Flink | Yes | Yes | Yes (native) |
| Trino / Presto | Yes | Yes | Yes |
| Snowflake | Yes (Iceberg Tables) | Via UniForm | No |
| Google BigQuery | Yes | Via UniForm | Limited |
| AWS Athena / Glue / EMR | Yes (default) | Yes | Yes |
| Amazon Redshift | Yes | Limited | Limited |
| Microsoft Fabric | Via UniForm | Yes (native) | No |
| Dremio / Starburst | Yes | Yes | Limited |
| DuckDB / ClickHouse | Yes | Read | Limited |
The “Via UniForm” entries are important: Delta’s Universal Format lets a Delta table expose Iceberg (and Hudi) metadata so that Iceberg-only engines like Snowflake and BigQuery can read it. That interoperability blurs the lines – a Delta table can present an Iceberg face – but it is read-oriented and does not change the underlying write path. If you need first-class read and write across the broadest set of engines and clouds with no translation layer, Iceberg remains the safest default in 2026. If your engines are Spark and Fabric, Delta is frictionless. If you are pushing Flink-based streaming with heavy upserts, Hudi is at home.
Pricing: The Format Is Free, the Platform Is Not
This is the section that surprises newcomers: as open-source projects, Apache Iceberg, Delta Lake, and Apache Hudi all cost exactly $0 to use. All three are Apache-2.0 licensed, with no per-core fees, no seat licenses, and no usage tolls on the format itself. What you actually pay for is the surrounding stack – compute to run queries, object storage to hold data, and optionally a managed catalog or platform to operate it all. The table below compares the pricing models, not the formats, because the format line item is always zero.
| Path to production | Format(s) | Pricing model | You manage |
|---|---|---|---|
| Self-managed OSS (Spark/Trino on K8s) | Any of the three | $0 format + raw cloud infra | Everything |
| AWS S3 Tables + Athena/EMR | Iceberg | S3 storage + per-query/compute + table maintenance | Pipelines |
| Databricks | Delta + Iceberg (Managed) | DBU consumption + cloud infra | Notebooks/jobs |
| Snowflake | Iceberg Tables | Credit consumption (per-second compute) | SQL workloads |
| Microsoft Fabric | Delta (OneLake) | Capacity Units (reserved/pay-go) | Workspaces |
| Onehouse | Hudi (universal) | Managed subscription | Ingestion config |
The financial implication of this is the real reason open table formats matter to a CFO, not just an architect. Because the table format is free and engine-agnostic, you can store data once and run the cheapest available engine against it – DuckDB for ad-hoc work, Trino for interactive SQL, Spark for heavy ETL – instead of paying a single warehouse vendor for every workload. That is the same FinOps logic driving the broader cloud-cost conversation; see our breakdown of Snowflake vs Databricks vs BigQuery pricing for how the compute layer stacks up once the storage layer is open. The catch is operational: self-managed open source trades license fees for engineering time, and the managed platforms exist precisely because running compaction, clustering, and catalog services well is non-trivial.
Interoperability: XTable, UniForm, and the End of Lock-In
One of the most consequential trends of 2025â2026 is that you increasingly do not have to choose a single format forever. Two interoperability technologies make tables multilingual. Delta UniForm (Universal Format) writes a Delta table while simultaneously generating Iceberg and Hudi metadata, so a single physical table can be read as any of the three. Apache XTable (formerly OneTable, now Apache-incubating at version 0.3.0) goes further with omni-directional metadata translation: point it at a table written in one format and it generates the metadata for the others, no data copy required.
These tools matter because they lower the stakes of the decision. If you adopt Delta inside Databricks today, UniForm keeps your tables readable from Snowflake and BigQuery. If you standardized on Hudi for ingestion, XTable can expose an Iceberg view for your analytics engines. They are not magic – translation only covers metadata, write paths remain format-specific, and edge cases around deletes and advanced features can lag – but they meaningfully reduce the cost of being wrong. A typical XTable sync that exposes a Hudi table as Iceberg looks like this:
# Apache XTable: translate a Hudi table into Iceberg metadata
java -jar xtable-utilities.jar
--datasetConfig my_config.yaml
# my_config.yaml
sourceFormat: HUDI
targetFormats:
- ICEBERG
datasets:
- tableBasePath: s3://lake/rides
tableName: ridesReal-World Deployments: Netflix, Uber, Apple, and More
Abstract capability tables only get you so far; the clearest signal is who runs what at scale and why. These five real-world patterns map directly onto the strengths discussed above.
- Netflix – Iceberg at petabyte scale. Iceberg was born at Netflix to make atomic, fast operations possible on enormous S3-backed tables where Hive’s directory model had collapsed. Netflix remains a flagship Iceberg user and the source of much of its design DNA.
- Uber – Hudi for near-real-time data. Uber created Hudi to ingest constantly-updating trip and marketplace data into the lake within minutes, using record-level upserts and incremental pulls rather than full table rewrites – the canonical streaming-upsert use case.
- Apple, LinkedIn, and Adobe – Iceberg for open analytics. Each runs Iceberg to keep massive datasets queryable across multiple engines without committing to one vendor’s compute, a pattern that helped tip the industry toward Iceberg as the default.
- Microsoft Fabric customers – Delta via OneLake. Enterprises standardized on Microsoft’s analytics stack get Delta by default because OneLake is Delta-native, illustrating how platform gravity, not just technical merit, drives format adoption.
- AWS-native shops – Iceberg via S3 Tables. Teams that live in Athena, Glue, and EMR increasingly default to Iceberg now that S3 Tables provides native, managed Iceberg storage with automatic maintenance, removing the operational burden that once pushed teams toward proprietary warehouses.
The throughline is that format choice tracks workload and platform far more than it tracks raw benchmarks. Streaming and CDC pull toward Hudi; Spark and Microsoft pull toward Delta; open, multi-engine analytics pull toward Iceberg. The companies that picked well picked for their dominant workload, then used interoperability tools to cover the edges.
Use-Case Recommendations: Which Table Format Should You Choose?
Stripping away the politics, here is how to map your situation to a format. These recommendations assume you want the path of least resistance for your dominant workload, with interoperability as a safety net.
- Building a new, vendor-neutral lakehouse: choose Apache Iceberg. The broadest engine support, the strongest catalog ecosystem, and hyperscaler defaults make it the safest long-term bet, and v3 closes the remaining feature gaps.
- All-in on Databricks or Microsoft Fabric: choose Delta Lake. It is the native, best-optimized format in both, and UniForm keeps your tables readable from Iceberg engines when you need them.
- Streaming ingestion, CDC, or heavy upserts: choose Apache Hudi. Its record-level index, Merge-on-Read tables, and non-blocking concurrency are purpose-built for mutable, high-frequency data.
- AWS-centric analytics with minimal ops: choose Iceberg on S3 Tables for managed storage with automatic compaction across Athena, Glue, and EMR.
- Multi-cloud or multi-engine by mandate: choose Iceberg with a REST catalog (Polaris, Unity, or Glue) so neither storage nor governance ties you to one cloud.
- Already invested but worried about lock-in: stay put and add Delta UniForm or Apache XTable rather than migrating; translation is cheaper and faster than a rewrite.
Migration Guide: Moving Between Iceberg, Delta, and Hudi
Sooner or later many teams want to migrate – usually toward Iceberg for portability, or to consolidate two formats acquired through mergers. There are three broad strategies, in increasing order of effort and decreasing order of risk to your write pipelines.
Strategy 1: Metadata Translation (No Data Copy)
The lowest-effort option is to leave the data in place and generate the target format’s metadata with Apache XTable or Delta UniForm. This is ideal when you want to read a table in a new format without disturbing the existing writer. Because no Parquet files move, it is fast and cheap, and it is reversible. The limitation is that the original format remains the system of record for writes.
Strategy 2: In-Place Adoption (Reuse Existing Parquet)
If you want a true format switch but want to avoid rewriting data, several engines can adopt existing Parquet files into a new Iceberg table by generating metadata that points at them. Iceberg’s add_files and snapshot procedures, and Delta’s CONVERT TO DELTA, do exactly this. You get a native table in the new format while reusing the bytes already on disk; only metadata is written.
-- Adopt existing Parquet into an Iceberg table (Spark)
CALL lake.system.add_files(
table => 'lake.analytics.events',
source_table => '`parquet`.`s3://lake/legacy/events`'
);
-- Convert an existing Parquet directory to Delta
CONVERT TO DELTA parquet.`s3://lake/legacy/orders`;Strategy 3: Full Rewrite (CTAS)
The cleanest but most expensive route is a full Create Table As Select into the new format, which re-optimizes file sizes, partitioning, and clustering along the way. Use it when the source layout is poor, when you are changing partition strategy, or when you want a pristine table with no legacy baggage. Run it as a backfill, validate row counts and checksums, then cut over writers. Whichever strategy you pick, validate with a reconciliation query and keep the source table until you are confident – the formats are interoperable enough that a careful migration carries little permanent risk.
-- Full rewrite into a fresh Iceberg table
CREATE TABLE lake.analytics.events_v2
USING iceberg
PARTITIONED BY (days(ts))
AS SELECT * FROM delta.`s3://lake/legacy/events`;
-- Reconcile before cutover
SELECT (SELECT count(*) FROM lake.analytics.events_v2) AS new_rows,
(SELECT count(*) FROM delta.`s3://lake/legacy/events`) AS old_rows;Pros and Cons of Each Table Format
Apache Iceberg – pros: broadest engine and cloud support, strongest catalog ecosystem, true partition evolution and hidden partitioning, hyperscaler defaults, and a mature v3 spec. Cons: streaming upserts are less turnkey than Hudi, and the catalog landscape, while rich, is still consolidating.
Delta Lake – pros: rock-solid transaction log, best-in-class inside Databricks and Microsoft Fabric, Liquid Clustering, and UniForm interoperability. Cons: still most at home on Spark, and full feature parity on non-Spark engines depends on the maturing Delta Kernel.
Apache Hudi – pros: unmatched for streaming upserts and CDC, powerful record-level and secondary indexing, non-blocking concurrency, and the most database-like feature set. Cons: smaller ecosystem and mindshare, weaker hyperscaler endorsement, and a steeper configuration learning curve.
Verdict: The 2026 Open Table Format Winner
If you want a single answer: in 2026, Apache Iceberg is the default choice for new, open lakehouses, and the data backs it up. Every major cloud – AWS, Snowflake, Google, and even Delta’s creator Databricks – now reads and writes Iceberg; the Tabular acquisition put Iceberg’s creators inside the company that built the competing format; S3 Tables made Iceberg the native AWS option; and Iceberg v3 erased the last meaningful feature gaps with deletion vectors, row lineage, and a VARIANT type. When the format you compete against adopts your format, the argument is effectively over.
But “winner” is the wrong frame for a healthy team. Delta Lake is not losing inside its strongholds – if your world is Databricks or Microsoft Fabric, Delta is the right answer and UniForm hands you Iceberg compatibility for free. Apache Hudi is not losing where mutation matters – for streaming ingestion, change data capture, and high-frequency upserts, its index and Merge-on-Read engine remain the most purpose-built tools available. And thanks to UniForm and Apache XTable, the decision is no longer permanent: you can write one format and expose the others, which means the smartest 2026 strategy is to optimize for your dominant workload and let interoperability cover the rest. Choose Iceberg if you are unsure; choose Delta or Hudi if your platform or workload clearly calls for them; and choose a REST-compatible catalog no matter what, because the next battleground is governance, not file layout.
Frequently Asked Questions
Is Apache Iceberg better than Delta Lake?
For open, multi-engine lakehouses, Iceberg is the safer default in 2026 thanks to broader engine support, a richer catalog ecosystem, and hyperscaler backing from AWS, Snowflake, and Google. Inside Databricks or Microsoft Fabric, however, Delta Lake is better optimized and more frictionless. With Iceberg v3 and Delta 4.0, their raw capabilities have largely converged, so the better choice depends on your platform more than on the format itself.
What is the main difference between Hudi and Iceberg?
Hudi was built around fast record-level upserts and streaming ingestion, with a record-level index and Merge-on-Read tables that absorb high-frequency updates. Iceberg was built as a vendor-neutral specification optimized for large-scale, multi-engine analytics with strong partition evolution and a broad catalog ecosystem. Choose Hudi for mutable, streaming data; choose Iceberg for open analytics across many engines.
Do open table formats cost money?
No. Apache Iceberg, Delta Lake, and Apache Hudi are all free, Apache-2.0 licensed open-source projects. You only pay for the surrounding infrastructure – compute engines, object storage, and optionally a managed platform like Databricks, Snowflake, AWS S3 Tables, or Onehouse. The format itself never carries a license fee, which is a core reason the lakehouse pattern is so cost-attractive.
Can I convert between Iceberg, Delta, and Hudi?
Yes. Delta UniForm lets a Delta table expose Iceberg and Hudi metadata simultaneously, and Apache XTable performs omni-directional metadata translation between all three without copying data. For a permanent switch, you can also adopt existing Parquet files into a new format’s metadata or do a full rewrite. Translation covers reads well; write paths remain format-specific, so plan accordingly.
What is Apache Iceberg v3?
Iceberg v3 is the third major version of the table format specification, which reached general availability on Snowflake in May 2026 and public preview on Databricks. It adds seven capabilities – deletion vectors, row lineage, a VARIANT type, default column values, geometry and geography types, nanosecond timestamps, and multi-argument partition transforms. Deletion vectors alone can make merge-heavy updates up to 10x faster than the v2 approach.
Which table format do AWS, Snowflake, and Databricks use?
AWS defaults to Iceberg across Athena, Glue, EMR, and the native S3 Tables storage. Snowflake supports Iceberg Tables and contributed the Polaris catalog to Apache. Databricks created and still champions Delta Lake but now also offers Managed Iceberg and open-sourced Unity Catalog. Microsoft Fabric is Delta-native via OneLake. In short, Iceberg is the cross-vendor common denominator, while Delta dominates the Databricks and Microsoft ecosystems.
Is Delta Lake only for Spark?
Not anymore. Delta Lake began as a Spark-centric format, but Delta Lake 4.0 introduced Delta Kernel, a single core library that lets non-Spark engines such as Trino and Flink read and write Delta through one consistent implementation instead of bespoke connectors. Delta is still best-optimized on Spark, but its engine reach has widened considerably.
Should I migrate my existing data lake to Iceberg?
If portability and multi-engine access are priorities, Iceberg is worth migrating to – but start with low-risk metadata translation via Apache XTable rather than a full rewrite. Validate reads, then decide whether to switch your write path. If you are happy inside Databricks or Microsoft Fabric, you may not need to migrate at all; UniForm can expose your Delta tables to Iceberg engines without moving data.
