Apache Iceberg vs Delta Lake: No Fluff, Just the Decision

If you searched "Iceberg vs Delta Lake" expecting a feature checklist - who has time travel, who has row-level deletes, who has schema evolution - here is the uncomfortable update: that comparison is over, and it ended in a tie. Both formats now have deletion vectors, row lineage, column mapping, merge-on-read deletes, hidden partitioning-style layout, and ACID commits on object storage. They got there from opposite directions - Apache Iceberg through a single format-version dial you turn from v1 to v4, Delta Lake through an a-la-carte set of "table features" - but the capability surface has converged so far that a 2024-era feature table tells you almost nothing useful in 2026.

So the decision moved. It is no longer "which format can do X." It is: which ecosystem do you want to live in, which catalog do you bet on, how much of your platform is Databricks, and how much does the new interop layer let you avoid choosing at all. This post walks those axes - the ones that actually decide it - and skips the internals, which the two deep-dives above already cover.

The one-paragraph answer

If you want the short version so you can stop reading: pick Iceberg if "open and multi-engine" is the priority - many query engines, many clouds, a vendor-neutral catalog, and freedom to swap compute later. Pick Delta if your center of gravity is Databricks or Spark - you get the deepest, best-tuned integration and, thanks to UniForm, your Delta tables are readable by Iceberg engines anyway. And the interop layer - the Iceberg REST catalog and Delta UniForm - genuinely softens the choice. But read the fine print before you relax: the lock-in didn't disappear with convergence, it moved up a layer - from the file format to the catalog. Databricks' own Iceberg support is the sharpest example, and section 3 is where that story gets real. The rest of this post is why.

Same idea, two lineages

Both formats solve the identical problem: a pile of Parquet files in object storage has no transactions, no atomic commits, no safe concurrent writes, and no time travel. Both fix it by adding a metadata layer that turns "a directory of files" into "a table." The difference is the shape of that metadata, and it colors everything downstream.

• Iceberg is a tree of immutable metadata behind a single catalog pointer. Every commit writes new metadata files and atomically swaps one pointer. The catalog holds exactly one fact per table - the current root - and that swap is the only contended operation in the system. Because the tree is engine-neutral and self-describing, any engine that implements the spec can read and write it. The full mechanics are in How Apache Iceberg Grew Up.

• Delta is an ordered, append-only transaction log next to the Parquet. The _delta_log/ directory holds numbered JSON commits (periodically checkpointed to Parquet); the log is the source of truth, and reconstructing table state means replaying it. Delta grew by a ladder of protocol versions and then pivoted to table features. The mechanics are in How Delta Lake Grew Up.

Neither shape is "better" in the abstract. But "tree of metadata a catalog points at" was built from day one to be read by many engines through a neutral catalog, while "transaction log the writer replays" grew up inside Spark. That origin difference is still visible in 2026, and it is most of what the decision turns on.

Where they've converged (so ignore old comparisons)

A large fraction of the "Iceberg vs Delta" content on the web is stale because it predates this convergence. As of 2026, both formats have essentially the same core capabilities:

If a comparison you're reading leans hard on "Delta has X and Iceberg doesn't" (or vice versa) for anything in that table, it's out of date. The features are no longer the differentiator. The ecosystem around them is.

Where they still differ (the axes that decide it)

1. Engine and ecosystem breadth

This is Iceberg's clearest structural advantage. Iceberg was designed as an open spec that many engines implement independently, and the market has rewarded that: Spark, Flink, Trino, Presto, Dremio, Snowflake, BigQuery, Amazon Athena, ClickHouse, StarRocks, and more can read - and in many cases write - the same Iceberg table concurrently. If your plan is "multiple engines against one copy of the data," Iceberg is the path of least resistance.

Delta's read/write story outside Spark historically depended on Databricks or the Spark connector. That's improving - the Delta Kernel project exists precisely to let non-Spark engines implement Delta correctly without reimplementing the whole protocol - but the breadth and maturity of native multi-engine support still favors Iceberg today. If you're a Spark shop, this gap may not matter to you at all. If you're not, it's decisive.

2. The catalog story

A table format needs a catalog to answer "what is the current version of this table," and this is where the two philosophies diverge most.

Iceberg treats the catalog as a pluggable, engine-neutral interface. Hive Metastore, AWS Glue, JDBC, Nessie, Snowflake's Polaris, and others all implement it, and the Iceberg REST catalog spec has become the de facto industry standard for how an engine talks to a catalog. That standardization is why Snowflake built Polaris, AWS shipped S3 Tables, and Google shipped BigLake Managed Tables - all speaking the same REST catalog protocol. Bet on Iceberg and you're betting on the interface everyone else is also implementing.

Delta's richest catalog experience is Unity Catalog on Databricks, which handles governance, lineage, and access control tightly integrated with the platform. Unity Catalog is now open-sourced and, notably, also implements the Iceberg REST catalog API - which tells you where the wind is blowing. If your governance story is already Unity Catalog, Delta is the natural fit; if you want a catalog that any vendor's engine can talk to out of the box, Iceberg's REST standard is ahead. But "Unity Catalog speaks Iceberg REST" hides a catch that's important enough to get its own section next.

3. The Databricks factor, and its catch

You cannot reason about this decision honestly without accounting for Databricks, and their position is genuinely unusual: Databricks created Delta Lake, then in 2024 acquired Tabular - the company founded by the original creators of Iceberg. They now employ the people who built both formats. No other vendor has that, and it makes their behavior the single strongest signal in the whole debate.

The upside is genuine. Delta on Databricks is still the most deeply tuned, best-supported path when Databricks is your platform - liquid clustering, predictive optimization, and the closest Photon/Spark coupling show up there first. And Databricks has leaned into Iceberg instead of resisting it: since 2025, Unity Catalog serves a native Iceberg REST Catalog endpoint, so outside Iceberg engines like Spark, Flink, and Trino can both query and write the Iceberg tables Databricks manages. Marketed that way, it sounds like Iceberg with nothing given up.

The part the marketing skips is the shape of that openness: it flows inward only, and always by way of Unity Catalog. Three details, all checkable in Databricks' own docs, are worth pinning down before you build on it:

• Unity Catalog isn't a default you can swap out - it's a prerequisite. A managed Iceberg table needs a Unity-Catalog-enabled workspace, and there's no LOCATION you can set to hand the metadata path to something else; Databricks keeps that path. The move people assume they can make later - "it's Iceberg, so I'll just aim Polaris or Glue at the same files and walk" - isn't on the menu. Getting out means rewriting the tables, which at petabyte scale is precisely the trap Iceberg was pitched as avoiding.
• The REST bridge is a one-way street. Other engines can point at Unity Catalog and work with its tables, but Databricks compute won't run the reverse: it can't be configured as an Iceberg REST client against a Polaris, Nessie, or Glue catalog. Tables those catalogs own show up as "foreign," and Databricks will only read them - it can't write them or drive their maintenance. So a Flink job writing an Iceberg table in Glue is visible to Databricks but not something it can fully join in on.
• The governance perimeter is exactly the UC perimeter. The scoped, expiring credentials Unity Catalog hands out - one of the main reasons people standardize on it - don't extend to those foreign tables. The moment you step outside Databricks-owned data, you're wiring up storage credentials yourself, and the centralized access story you bought into stops at the edge.

None of this makes Delta-on-Databricks the wrong call. It just means the "it's open Iceberg" pitch is only half true: you get the Iceberg file format, wrapped in Unity Catalog's governance. Read Databricks' moves together and the pattern is clear - they'll meet you on the format and hold the line on the catalog. That's the tell for where lock-in actually lives now, and it's the question the next section has to answer.

4. UniForm and the "you don't have to choose" era

The single most important development for this decision is that it's becoming reversible. Delta UniForm writes a Delta table and simultaneously generates Iceberg (and Hudi) metadata against the same single copy of Parquet data - no duplication, no second pipeline. An Iceberg-compatible engine (Snowflake, Athena, BigQuery, Trino) can then read that table as if it were native Iceberg, while Databricks writes it as Delta.

That softens the old fear - "if I pick wrong, I'm stuck rewriting petabytes" - for the common case of one writer and many readers. Write Delta natively in Databricks, expose it to Snowflake/Athena/BigQuery/Trino via UniForm, and you've bought yourself real optionality on the read side.

But apply the same honesty from the last section, because UniForm is not a symmetric escape hatch:

• It's read-mostly. Iceberg engines read the generated metadata; Delta remains the writer. It solves "let other engines query my table," not "let me hand the table to a different writer and walk away."
• The catalog is still the real lock-in. Section 3's catch applies here too: the interop runs through Unity Catalog, inbound-only, and managed tables have no LOCATION you can repoint. UniForm frees the format; it does not free the catalog.
• So "keep your options open" has an asterisk. You keep your options open for readers. Your writer, your governance, and your exit path are still anchored to whichever catalog owns the table.

The industry phrase is "write once, read anywhere," and by 2026 it's real enough to plan around - as long as you plan around what it actually is. The format is becoming a runtime detail. The catalog is becoming the thing you're actually choosing, and the thing that's actually hard to leave.

5. Streaming, CDC, and operational ergonomics

For streaming ingestion and change data capture, both are capable, but the defaults differ. Delta's tight Spark Structured Streaming integration and Change Data Feed make it ergonomic for Spark-centric CDC and incremental pipelines. Iceberg pairs naturally with Flink for streaming writes and has strong support for equality deletes that suit streaming upserts. Neither is a knockout; pick the one that matches the streaming engine you already run.

On day-two operations - compaction, snapshot/version expiration, small-file cleanup - both need active maintenance, and both provide the tools. On Databricks, much of it is automated (predictive optimization); on open Iceberg, you'll wire up the maintenance actions yourself or lean on a managed catalog that does it.

The decision, distilled

You rarely get a clean "X wins." You get "given your constraints, X." Here's how the constraints map:

Choose Apache Iceberg if:

• You run - or want to keep the option to run - multiple query engines against one copy of your data.
• You want a vendor-neutral catalog and are betting on the open REST catalog standard the rest of the industry is adopting.
• You're multi-cloud, or want to avoid coupling your table format to any single compute vendor.
• Snowflake, BigQuery, Trino, or Athena are first-class consumers of your lake.

Choose Delta Lake if:

• Databricks or Spark is the center of gravity of your platform.
• You want the deepest, best-tuned integration and the newest optimizations first.
• Unity Catalog is already your governance and access-control layer.
• You value UniForm as a safety valve - write Delta, stay readable by Iceberg engines - more than native multi-engine writes.

You can defer the format choice - but not the catalog choice:

• You're on Databricks anyway: write Delta, turn on UniForm, expose Iceberg metadata to external readers. You get Delta's integration and Iceberg's read reach from one copy of the data - just know that the writer and the exit path stay tied to Unity Catalog, which controls the metadata path and can't be repointed without rewriting the tables.
• The choice you can't defer is the catalog. Whichever one owns your tables - Unity Catalog, Polaris, Glue, Nessie - is the thing you're actually committing to, because interop between them is still asymmetric (Databricks reads foreign Iceberg tables but won't write them; it won't act as a client of an outside catalog at all). Choose the catalog as deliberately as you'd choose the format.

The cheat sheet

The throughline

The honest 2026 answer to "Iceberg or Delta" is that the feature war is over, the formats have converged, and the lock-in moved up a layer - from the file format to the catalog. UniForm and the Iceberg REST catalog do let one copy of your data live in both worlds, but only asymmetrically: readers roam free, writers and governance stay anchored to whichever catalog owns the table. Databricks' Iceberg support is the clearest tell - real, but gated behind Unity Catalog and pointed one direction only.

So choose accordingly. Iceberg is the safer bet for open, multi-engine, vendor-neutral architectures. Delta is the safer bet if Databricks is your home and you want the deepest integration - with eyes open to the Unity Catalog gravity that comes with its "open Iceberg" story. Either way, spend as much care on the catalog as on the format, because by 2026 that's the decision that's actually hard to reverse.

If you want to understand why each format behaves the way it does - the metadata tree, the transaction log, deletion vectors, and how commits stay atomic on object storage - read the two deep-dives this post leans on: How Apache Iceberg Grew Up and How Delta Lake Grew Up. Both are part of the broader open table formats curriculum, which builds the whole picture from first principles - why data lakes broke, and how snapshots, manifests, and logs put them back together.