Databricks Field Guide

Databricks runs both Delta Lake and Iceberg, and Delta is the default

Databricks supports two open storage formats for tables, Delta Lake and Apache Iceberg, and the documentation on table concepts, last updated on 11 September 2026, says Delta Lake is the default format for managed and external tables. Iceberg is supported for managed and foreign tables, and the docs describe it as the format to use when you're integrating with Iceberg tooling. Both add a transactional layer over Parquet files that gives ACID guarantees, time travel and schema evolution, so the choice is rarely about what the format can do.

What the formats actually share #

Both Delta Lake and Iceberg sit as a metadata layer on top of data files in object storage. Databricks' own description of them is identical on the capabilities that teams usually compare: atomicity, consistency, isolation and durability, plus time travel. A reader arriving at this question expecting one format to be transactional and the other not will find the documentation gives them the same guarantees.

Where they differ on Databricks is in what the platform does for you. Managed tables, which Unity Catalog owns end to end, get automatic performance optimisation and storage cost optimisation. External tables are read and written but optimised manually only. Foreign tables, which point at a catalog another system owns, are read-only from Databricks. The table type decides more about your operational life than the file format does.

Reading Delta tables from Iceberg clients #

If the pressure to pick Iceberg comes from a tool outside Databricks, there may be nothing to pick. Databricks documents Iceberg reads on Delta tables, available in Databricks Runtime 14.3 LTS and above, which configures a Delta table to generate Iceberg metadata automatically so Iceberg clients read the data without rewriting files. Both formats are Parquet underneath with a metadata layer on top, which is what makes this possible.

Iceberg itself keeps moving on the platform. Databricks announced that its support for Apache Iceberg v3 entered Public Preview, bringing the newer spec features natively.

How to decide in practice #

Ask which engine owns the write path. If Databricks writes the table and everything else reads it, Delta with Iceberg reads enabled covers both sides. If another platform's catalog owns the table and Databricks is one of several readers, you're looking at a foreign table, which is read-only here, and the format question is settled by whoever owns the data.

The third format in most comparisons, Apache Hudi, is covered in the Databricks blog on open table formats but is not one of the two storage formats Databricks supports for its own tables.

More on how this maps to catalogs and governance is in Tables and Storage and Unity Catalog.

Questions people ask #

What is the difference between Delta Lake and Apache Iceberg on Databricks? #

Both are open storage formats that add ACID transactions, time travel and schema evolution over Parquet files. On Databricks, Delta Lake is the default storage format for managed and external tables, while Iceberg is supported for managed and foreign tables and is useful when integrating with other Iceberg tools and catalogs.

Can Iceberg clients read Delta Lake tables? #

Yes. Databricks documents Iceberg reads, available in Databricks Runtime 14.3 LTS and above, which configures Delta Lake tables to automatically generate Iceberg metadata so Iceberg clients read the data without rewriting files.

Does Databricks support Apache Iceberg v3? #

Databricks announced that its support for Apache Iceberg v3 entered Public Preview, bringing the latest Iceberg community features natively to the platform.

Update, 9 October 2026 #

Iceberg v3 is no longer in preview. Databricks' May 2026 release notes record that on 21 May 2026 Unity Catalog managed Apache Iceberg tables, foreign Apache Iceberg tables and Apache Iceberg v3 features all became generally available, and the Databricks blog on Unity Catalog and the next era of Apache Iceberg says the same three moved to GA. The Public Preview wording above describes the earlier stage of the same feature.

What GA buys you is the v3 feature set on managed tables. That means deletion vectors for row-level deletes without rewriting data files, the VARIANT type for semi-structured data, row lineage, GEOMETRY and GEOGRAPHY types, and write defaults. The v3 documentation, last updated on 11 September 2026, requires a Unity Catalog workspace and Databricks Runtime 18 LTS or above, which is the constraint most teams will hit first. Existing tables upgrade by setting format-version to 3 on an Iceberg table, or delta.enableIcebergCompatV3 on a managed Delta table with Iceberg reads, and a table can be downgraded to v2 only by using RESTORE to a version from before the upgrade.

Our position does not move. Delta is still the default for managed tables and still the right starting point, with Iceberg reads turned on when an outside engine needs them. The difference now is that choosing Iceberg as the storage format, where another system governs the write path, no longer means running a preview feature in production.

Next

Lakeflow Jobs is the orchestrator, and its history is a queryable table