Delta Lake vs Apache Iceberg: Which Table Format to Choose

Somebody picks a platform, the platform has a default, the default becomes the format, and nobody writes it down. That is why this is not an engineering preference. It is the one decision in a lakehouse build that determines who can read your data without your current vendor's permission.

The reason this article needed rewriting in 2026 is that the interoperability layer has moved faster than almost anything else in the data stack. The stakes are materially lower than they were two years ago — but the decision still has to be defended to a CFO who suspects it is a lock-in choice dressed as a technical one.

An open table format is a publicly specified metadata layer that turns a folder of Parquet files into a database table. It adds ACID transactions, enforced schema with schema evolution, versioned history and time travel, and safe concurrent writes. Bare Parquet is a file layout — it stores columns efficiently and nothing else.

Both formats fix all four the same way: by keeping an authoritative record of which files constitute the table at each committed version, and refusing to let a reader see anything not yet committed. This is also what keeps a lake from degrading into a data swamp.

Delta Lake keeps an ordered transaction log — numbered JSON commit files in a _delta_log folder beside the data — where each commit lists the Parquet files added and removed. The table is not the folder; the table is the log. Delta Lake 4.1.0 (01-Mar-2026) brought full production support for catalog-managed tables, moving commit coordination to a catalogue rather than relying on atomic file operations in object storage.

Apache Iceberg keeps a metadata tree: a table metadata file points to a snapshot, which points to a manifest list, which points to manifests and finally data files. The atomic act of committing is swapping a single pointer in a catalogue from the old metadata file to the new one. Iceberg has always required a catalogue to be correct, not merely convenient — which is why the Iceberg REST Catalog specification, not the file format, became the real battleground between vendors.

In day-to-day operation the differences appear in four places, and none of them decides the platform on its own. Partition evolution is Iceberg's clearest structural advantage — the partition spec can change without rewriting existing data, where Delta addresses the same need through liquid clustering. Schema evolution is clean in both for added columns; renames in Delta require column mapping to be enabled.

Small files and compaction degrade both formats under frequent small writes — the normal shape of MES, SCADA and telematics ingestion — so both need scheduled maintenance. Concurrency uses optimistic detection at commit in both. These are operational realities to plan for, not decision criteria.

Engine support is the question that decides the format for most businesses. Delta Lake has documented connectors for Apache Spark, Trino, Starburst, Presto, Amazon Redshift Spectrum, Snowflake, Google BigQuery and Apache Flink, and is the native format of Microsoft Fabric and Azure Databricks. Iceberg is natively written by Snowflake, AWS, Google Cloud, Dremio and Starburst.

The honest summary is that both formats are readable nearly everywhere and natively writable in fewer places. Microsoft states that Fabric uses Delta Lake as its universal storage format across all workloads and that OneLake stores all data as Delta Parquet by default. If your estate is already Microsoft-committed, this is not a close call.

As at August 2026, Delta Lake and Apache Iceberg are broadly interoperable for reading and largely not interoperable for writing. Delta tables can be exposed to Iceberg clients through Delta UniForm and catalogue endpoints; Iceberg tables can be read as Delta in OneLake through metadata virtualisation. That single asymmetry is the sentence to take to a CFO: you will always be able to read your data with another vendor's engine.

Underneath the vendor plumbing, the specifications are converging. Iceberg v3 adopted deletion vectors using the same binary encodings across formats and row lineage compatible with Delta Lake's row tracking, while Delta 4.1.0 moved commit coordination into catalogues — matching Iceberg's model.

In Microsoft Fabric, OneLake writes Delta Parquet by default across every workload, and reads Apache Iceberg through metadata virtualisation rather than storing it natively from Fabric compute. For a buyer already committed to Fabric the position is straightforward: your format is Delta — warehouse, lakehouse, pipelines, Dataflows Gen2 and Power BI all land in Delta Parquet in OneLake. Iceberg data is welcome as an input — Snowflake on Azure can write Iceberg tables into a OneLake Files folder via an external volume, and a shortcut presents them as Delta to every Fabric workload.

The virtualisation has hard edges. Source tables must have fewer than 5,000 commits for conversion to occur; metadata generation takes between five seconds and two minutes; and Microsoft advises keeping updates to the source table less frequent than once every two minutes. Delta feature support inside Fabric is also not uniform across engines — liquid clustering is read-only in several, Python notebooks use delta-rs rather than the Spark reader and writer, and some Delta 4.x features are not yet universal.

Cross-format access is read-only, and that is the lock-in that remains. Every interoperability path gives a foreign engine read access, not write. But the format is not the lock-in that will actually cost you — pipelines, orchestration, semantic models, row-level security definitions, notebooks and capacity configuration are not portable in either format.

Interoperability features carry version and volume limits that are easy to breach — Iceberg V3 tables are not yet readable through OneLake's virtualisation. Neither format fixes data quality: ACID guarantees a write either fully happened or did not, nothing more. Maintenance is real work in both — compaction, snapshot expiry and vacuum need a named owner. And time travel is bounded by retention, and retention costs money.

Four rules, applied in order — most businesses stop at rule one. If your platform has a native format, use it (Fabric writes Delta). If you are genuinely multi-platform with two writers, choose by who writes — the format follows the engine that owns the write. If you are choosing the platform now, choose on cost, skills and serving requirements, not on the format. And if a vendor tells you the format decision is irreversible, ask which specific write path they mean — the read paths are documented and dated.

Answer these four this week, before anyone opens an architecture tool:

• How many engines will write to your analytical tables — not read, write? If the answer is one, this decision is nearly free
• Which non-Microsoft consumer will need this data in the next 24 months — a customer, a 3PL partner, an auditor, a data science team? Name it
• What is your update frequency per table? Anything under two minutes rules out relying on OneLake cross-format virtualisation for that table
• Who owns table maintenance — compaction, retention, snapshot expiry — after go-live? Name a person, not a team

Question four decides more outcomes than the format does. We build these estates on Microsoft Fabric, OneLake and Power BI, with Power Automate and Copilot Studio closing the loop from insight to action.