On this page · 9 sections
Summary. The table format is the one lakehouse decision that is hard to reverse, and in 2026 the two leaders are converging rather than diverging. Apache Iceberg's v3 spec was ratified in mid-2025, and the 1.10 and 1.11 releases through May 2026 added deletion vectors, a variant type for semi-structured data, row lineage and geospatial types. Delta Lake's UniForm publishes Delta tables so Iceberg clients can read them, and Databricks, which bought Iceberg's original creators at Tabular for more than $1 billion in June 2024, now ships Iceberg v3 as a first-class format under Unity Catalog. Snowflake Horizon reached general availability for Iceberg reads in February 2026. Both formats sit on the same Apache Parquet files in object storage that costs about $0.023 per GB on Amazon S3, so the differentiator is not storage. It is engine reach, governance and how much you trust the convergence. This guide shows where each format still leads and how to pick without locking yourself in.
Ten years ago the choice was Parquet files and hope. Today two open formats, Apache Iceberg and Delta Lake, add the database guarantees that raw files lack: ACID transactions, schema evolution and time travel over data that still lives as plain files in your own object storage. That is the shared foundation. The disagreement is about metadata design, which engines read the tables first-class, and whose catalog governs them. In 2026 that disagreement is narrowing fast, which changes the decision from "which format wins" to "which format fits, given that they increasingly read each other."
The person who arguably has the most authority on this saw it coming. Ryan Blue, who created Apache Iceberg at Netflix and now works at Databricks after it acquired his company Tabular, said the goal is "to build the best data management platform based on open lakehouse formats so that companies don't have to worry about picking the 'right' format or getting locked into proprietary data formats." That is a striking thing for the creator of one format to say while working at the company behind the other. It is also the most useful framing for this decision: choose for today's engine reach, but architect so a wrong guess is survivable.
What the two formats actually share
Before the differences, the common ground, because it is larger than vendor marketing suggests. Both Iceberg and Delta Lake are open-source table formats layered over Apache Parquet data files. Both give you ACID transactions so concurrent writes do not corrupt a table, schema evolution so you can add or rename columns without rewriting data, and time travel so you can query a table as it looked at an earlier snapshot. Both store their data on the same commodity object storage, whether that is Amazon S3, Azure Blob or Google Cloud Storage, at the same roughly $0.023 per GB. Neither format charges you: the cost is in the compute engine and the catalog you run on top.
That shared base is why the storage bill is not the deciding factor. You are not choosing a cheaper place to keep bytes. You are choosing which query engines treat your tables as native, which governance layer enforces permissions, and how portable the tables stay if you change either.
Where they differ, and why it is narrowing
The classic split: Iceberg was built engine-agnostic and reads first-class across Snowflake, Trino, Spark and Flink, while Delta Lake grew up inside the Databricks and Spark world and is strongest there. Iceberg uses a hierarchical, tree-based metadata layout, where a top-level metadata file points to a manifest list, which points to manifest files that hold the data-file list with column statistics. Delta uses a transaction log of ordered commits. Those designs led to a real difference in ecosystem breadth for years.
Two things closed most of the gap in 2025 and 2026. The first is Delta Lake UniForm, which publishes a Delta table with Iceberg metadata so that Iceberg clients can read it without a copy. The principle the industry settled on is write once, read anywhere. The second is Iceberg v3, ratified in mid-2025 and delivered through the 1.10 and 1.11 releases into May 2026. Iceberg v3 added deletion vectors, which began in Delta and are now Iceberg v3's centerpiece, with the same binary encoding used across Delta Lake, Parquet and Spark. It also added a variant type with shredding for semi-structured data, row lineage for change tracking, and geospatial types. The formats are now converging technically while keeping different design centers.
| Dimension | Apache Iceberg | Delta Lake |
|---|---|---|
| Design center | Engine-agnostic, multi-vendor analytics | Databricks and Spark pipelines |
| First-class engines | Snowflake, Trino, Spark, Flink and more | Databricks, Spark; others via UniForm |
| Metadata model | Tree of metadata file, manifest list, manifests | Ordered transaction log |
| Interop path | Native open format; read by many engines | UniForm publishes Delta as Iceberg |
| 2026 spec state | v3 ratified mid-2025; 1.11 line to May 2026 | v3 support GA on Databricks under Unity Catalog |
| Deletion vectors | Yes, v3 centerpiece | Origin of the feature |
The catalog is the real 2026 battleground
Once both formats read each other, the fight moves up a layer to the catalog, the service that tracks tables and enforces governance. This is where the 2026 decision actually lives.
Databricks Unity Catalog now implements the Iceberg REST Catalog APIs and integrates a growing set of external catalogs, including AWS Glue, Google Cloud's Lakehouse runtime catalog, Snowflake Horizon, Palantir, Salesforce and Workday. Managed Iceberg tables are open to the whole Iceberg ecosystem through those REST APIs. Snowflake Horizon takes the same open route: it implements the Apache-governed Iceberg REST specification, so if you leave Snowflake, any engine that speaks the Iceberg REST protocol can still read your tables. Horizon reached general availability for reads in February 2026, with external-engine writes in public preview as of March 2026. Cross-platform links have shipped too: reading Unity Catalog tables from Snowflake through a catalog-linked database went generally available in October 2025.
The practical read: the Iceberg REST catalog protocol is becoming the neutral interface, and both major vendors implement it. That is what makes "don't get locked in" achievable rather than a slogan. If you build on managed Iceberg tables exposed through a REST catalog, you keep the option to change engines later. The same open tables feed the engines that read Iceberg in place, which is where querying cross-cloud data without egress fees becomes practical, and they back both batch and real-time analytics on the lakehouse.
How to choose, by situation
| Your situation | Lean toward | Why |
|---|---|---|
| Multi-engine estate (Snowflake, Trino, Spark, Flink) | Iceberg | Native across the most engines; open REST catalog keeps it portable |
| Deep in Databricks and Spark today | Delta Lake, with UniForm on | Best in its home engine; UniForm still exposes it to Iceberg readers |
| All-in on AWS, want zero catalog ops | Iceberg on S3 Tables or Glue | Least operational effort; you accept some cloud coupling |
| Sharing data products across teams and vendors | Iceberg | Broadest external readability through the REST catalog |
| Latency-sensitive operational core plus shared analytics | Both, governed by one catalog | Delta for the hot core, Iceberg for shared products, one governance plane |
The hybrid in the last row is not a hedge, it is where many enterprises are landing: Delta Lake for the latency-sensitive operational core, Iceberg for data products shared across teams and platforms, and a single catalog such as Unity Catalog governing both. It captures each format's strength without duplicating storage, because UniForm and Iceberg v3 let one physical table serve both readers. Those same governed tables feed conversational analytics, where the cost of Databricks Genie vs Snowflake Cortex Analyst becomes the next decision on top of the format.
What convergence does not mean
It would be a mistake to read all this as "the choice no longer matters." It matters, for three reasons. First, first-class support is still not identical: a format that a given engine reads natively will usually be faster and better-featured than one it reads through a translation layer. Iceberg runs well inside Databricks as a production format as of June 2025, but Databricks itself notes it is equivalent to, not faster than, Delta there. Second, convergence is slow: when the acquisition closed, the companies cautioned it would take several years to reach a single common standard, and short-term compatibility runs through UniForm rather than a merged format. Third, governance semantics differ by catalog, so masking, tags and lineage do not always carry across a federation boundary unchanged.
So treat the convergence as insurance, not as permission to skip the decision. Pick the format your primary engine reads first-class today, expose it through an open REST catalog, and keep UniForm or Iceberg v3 interop on so the other half of your estate can read it.
India-specific considerations
For data teams in India, the open-format decision is also a sovereignty and cost decision. Because both formats keep data as your own Parquet files in your own object storage bucket, you control the region the data sits in, which is easier to reconcile with the Digital Personal Data Protection Act 2023 (DPDP) than a proprietary warehouse that holds your data inside its service. An open table format plus an open REST catalog means the governed data never has to leave a bucket you chose.
On cost, the discipline is the same one that decides cross-cloud query design: storage is cheap and roughly equal, so the money is in compute and in avoided lock-in. A team that standardises on an open format and a REST catalog preserves the ability to move a workload to a cheaper engine later, which for a growth-stage company watching burn is worth more than a small headline discount from a single vendor today. That is the same logic behind cloud FinOps for Indian teams: keep the workload portable and pay for the compute you actually use.
How eCorpIT can help
eCorpIT is a Gurugram-based, ISO 27001:2022-certified engineering organisation that designs and builds lakehouse platforms on open table formats. Our senior data engineers help you pick Iceberg or Delta Lake for your primary engine, set up an open Iceberg REST catalog so you keep the option to switch, and implement UniForm or Iceberg v3 interop so your whole estate reads one physical table. If you are standing up or replatforming a lakehouse in 2026, talk to us at /contact-us/.
FAQ
References
- Apache Iceberg vs Delta Lake — Starburst
- Apache Iceberg v3: moving the ecosystem towards unification — Databricks Blog
- Read Delta Lake tables with Iceberg clients using UniForm — Databricks Documentation
- Use Apache Iceberg v3 features — Microsoft Learn
- Advancing Apache Iceberg on Databricks: v3 GA and unified governance — Databricks Blog
- Databricks + Tabular — Databricks Blog
- Lakehouse table formats in 2026: Iceberg, Delta, Hudi, Paimon, DuckLake — AM DataLakehouse
_Last updated: 3 August 2026._
