Delta Lake and Apache Iceberg now match on core capabilities, so the choice comes down to three questions: which engine writes the table, which catalog governs it, and who must read it without a copy. A decision guide with the Microsoft Fabric interop paths.
A data lake is a pile of files. An open table format is the metadata contract that turns the pile into a database table: one schema, one history, safe concurrent writes. Two formats matter in 2026, Delta Lake and Apache Iceberg, and they now match on core capability, so the choice comes down to three questions: which engine writes the table, which catalog governs it, and who must read it without a copy. Answer them in order and the format picks itself. In Microsoft Fabric the first answer is pre-made, every engine writes Delta, so the decision moves to interop.
Scope
The framework holds anywhere; the final section maps it onto Microsoft Fabric. Product statuses verified against current documentation, August 2026.
Strip either format down and you find the same four layers: a catalog that turns a name into a table and points at the current version; table metadata holding schema, partitioning, and version history: which files are in the table right now; statistics and delete markers that let engines skip files and mark deleted rows in place; and plain Parquet data files: immutable, engine-neutral, identical in both formats.
Fig 1. Both formats manage the same Parquet files, the solid tile; the whole debate is the three metadata layers before it.
Delta Lake keeps its truth in a transaction log, a _delta_log folder inside the table folder itself. The table is self-describing. A catalog adds governance and multi-table transactions, but it is optional. Delta grew up inside Databricks and is the storage format of every Microsoft Fabric engine.
Apache Iceberg keeps its truth in the catalog, which holds the pointer to the current metadata file. No catalog, no table, and a catalog outage is a data outage. Iceberg grew up at Netflix so many engines could share one lake, and it is the open format Snowflake, AWS, and Google BigQuery write natively.
Almost every practical difference falls out of it. Delta tables travel well: the log rides along in the folder and file paths are normally relative to the table root, so copies and storage shortcuts just work. Iceberg references files by absolute path, so a copied table folder is unreadable until its writer rewrites the metadata; a v4 relative-path proposal is only now addressing this. Lock-in lands in different places too: Delta's in the platform, where the deepest features ship first; Iceberg's in the catalog, where the REST spec standardises the wire but the vendor keeps governance.
Capability no longer separates them. Iceberg's v3 spec added deletion vectors, row lineage, and a variant type for semi-structured data, exactly the features Delta advocates used to cite. Delta answered with UniForm (GA), which writes Iceberg metadata alongside the Delta log so Snowflake and BigQuery can read a Delta table as Iceberg. By 2026 the honest comparison is boring, and that is the point.
Six failures arrive on schedule in every lake without one.
Without
A job fails halfway and readers see half-written data
With
Atomic commits: readers see old or new, never a mix
Without
A column changes upstream and reports break silently
With
Schema is versioned and enforced; evolution is explicit
Without
Deleting one customer for privacy means rewriting terabytes
With
Row-level deletes mark rows; the files stay put
Without
A bad load overwrites good data with no way back
With
Every commit is a version: time travel, audit, rollback
Without
Queries list thousands of files and scan most of them
With
Per-file statistics skip what the engine does not need
Without
Two teams write the same folder and corrupt it
With
Optimistic concurrency detects the conflict and rejects one write
The cost
These guarantees are rented, and the rent is maintenance. Small files must be compacted, old versions expired, and the catalog run like the production system it is. A table format without an owner degrades within weeks, into slow queries and runaway storage rather than a clean error.
With capability converged, you are choosing between ecosystems. Five questions capture what differs.
| Question | Delta Lake | Apache Iceberg |
|---|---|---|
| Who writes it natively? | Microsoft Fabric (every engine), Databricks, Apache Spark | Snowflake, AWS (Glue, Athena, EMR), Google BigQuery, Spark, Flink, Trino |
| Does it need a catalog? | No. The log in the folder is the truth; a catalog adds governance | Yes. The catalog is the truth; its outage is a data outage |
| Can the table be moved? | Yes. Relative paths mean copies and shortcuts just work | Only by its writer. Absolute paths make copied folders unreadable |
| How do other engines read it? | UniForm or OneLake generate Iceberg metadata for Iceberg readers | Any engine that speaks the Iceberg REST catalog protocol |
| Where is the lock-in? | The platform: deepest features live in Databricks and Fabric | The catalog: the REST spec standardises the wire, the vendor keeps governance |
"Iceberg means no lock-in" is the most repeated half-truth here. The REST catalog spec makes engines interchangeable, and Apache Polaris graduating to a top-level Apache project (Feb 2026) gives it a vendor-neutral home, but governance, credentials, and access policy live in whichever catalog you commit to, and migrating catalogs takes quarters. You do not escape lock-in by choosing Iceberg. You move it.
Do not choose a format. Answer three questions in order; only one is about the format at all.
1. Which engine writes the table? Its native format wins. Fighting the writer means a translation layer on every commit, and translation layers are where consistency bugs live.
2. Which catalog governs it? The ten-year decision, longer-lived than the format. It sets governance, credential flow, and who can add a writer later.
3. Who must read it without a copy? This picks the interop layer, never the format. One writer per table; everyone else reads a projection.
| If your estate looks like this | Pick |
|---|---|
| Fabric or Databricks does the writing | Delta. Serve Iceberg readers through UniForm or OneLake's virtual Iceberg metadata |
| Snowflake, AWS, or Google does the writing | Iceberg. The only open format those platforms write natively |
| Many engines, no dominant platform | Iceberg plus a vendor-neutral REST catalog such as Apache Polaris. The one case where Iceberg wins on merit alone |
| Two platforms both want to write the same tables | Not a format problem. Fix ownership first: one writer per table |
Every Fabric engine writes Delta to OneLake: Spark, Warehouse, pipelines, mirroring. The SQL analytics endpoint and Direct Lake read Delta only. You do not get a format vote: the decision moves to question three. Three paths cover it.
Three guardrails keep those paths out of trouble.
The format debate is loud, but the load-bearing decisions sit on either side of it. Below it, your Parquet files are identical either way; above it, the writer picks the format and the catalog outlives both. Spend the argument where it pays: name one writer per table, commit to a catalog you can live with for a decade, and treat every other engine as a reader of a projection. Teams fighting about Delta versus Iceberg are usually having a proxy war over table ownership, and that war has no format-shaped solution.
Five levers control all Delta table performance in Microsoft Fabric: resource profiles, V-Order, OPTIMIZE and Liquid Clustering, default behaviors, and VACUUM. A decision framework for data engineers and Fabric architects working with Lakehouses at scale.
Copilot and Fabric Data Agents answer from your semantic model's metadata, so preparing the model is the real AI work. A persona-mapped, flowchart-driven guide with brownfield and greenfield checklists.
Beginner-friendly guide to choosing hash functions across Microsoft Fabric. Why Spark hash() breaks at scale, how to make SHA-256 match across Spark, Warehouse, and KQL, and a top-5 comparison on F64 SKU.
