Iceberg vs Delta Lake in short

Choose the table format by the engines that must read and write the table, not by feature lists. Delta Lake is the default on Databricks and is built around Spark. Apache Iceberg is the format with the open REST catalog protocol that engines use to share tables, and both Databricks and Snowflake can now read and write it through catalogs, with limits each vendor documents. A table format is the layer that turns a folder of Parquet files into a table with transactions and a schema.

If you run Databricks, our Databricks consulting and Databricks alternatives pages cover the platform decisions around it. If you run Snowflake, see Snowflake consulting and Snowflake alternatives. For the wider architecture, start with lakehouse architecture explained.

Delta Lake is an open-source storage framework hosted by the Linux Foundation, with an Apache 2.0 licensed repository on GitHub (delta-io/delta). At our check on 4 November 2026 its site listed release 4.4.0 on Spark 4.2.0. Its tables are Parquet files plus a transaction log. Apache Iceberg is an Apache Software Foundation table format for large analytic datasets. Its documentation lists support from Spark, Flink, Hive, Trino, Presto, Snowflake and BigQuery, among others. Both give ACID transactions, schema evolution and time travel on object storage, so the day-to-day feature gap is smaller than the debate suggests.

Databricks supports Iceberg tables that use Parquet and versions 1, 2 and 3 of the Iceberg specification, in two forms. Managed Iceberg tables are created in Unity Catalog, need Databricks Runtime 16.4 LTS or above, and need predictive optimization to be enabled. External engines read and write them (not views) through the Iceberg REST Catalog API. Foreign Iceberg tables, managed by a catalog such as AWS Glue, a Hive metastore or Snowflake Horizon Catalog, are read-only in Databricks. For the other direction, UniForm generates Iceberg metadata so Iceberg clients can read Delta tables, read-only.

The limits on the Databricks Iceberg page (last updated 2 November 2026) are the ones to test: Parquet is the only file format, Iceberg v2 position and equality deletes are not supported (v3 deletion vectors are used instead), branching and tagging are not supported, external engines cannot read Unity Catalog views, and credential vending is not supported on workspaces that use default storage. Partition evolution on managed Iceberg tables works through external engines using the Iceberg REST catalog, not through Databricks SQL.

Snowflake distinguishes Snowflake-managed Iceberg tables, where Snowflake is the catalog, from externally managed tables that use a catalog integration to a remote catalog such as AWS Glue or Snowflake Open Catalog. External engines reach Snowflake-managed tables through the Horizon Iceberg REST Catalog API. Reading v2 and v3 tables is supported. Writes are supported with limits: no CREATE TABLE AS SELECT from the external engine, no equality deletes, no tags or branches, no rollback to a previous snapshot, and no writes to shared tables. Snowflake native tables cannot be read by external engines this way, and several Snowflake features, including cloning, clustering and replication, are unavailable on externally managed tables.

1. List the engines first. Name every engine that must read the table and every one that must write it. A format that one of them reads poorly is the wrong format for that table.
2. Default to your platform's native format for tables only that platform writes. On Databricks that is Delta Lake, and it keeps every platform feature.
3. Use Iceberg for tables shared across engines. It is the format both vendors document an open path for, and the REST catalog protocol is how engines find it.
4. Pick the catalog before the format. The catalog decides access control and which engines can find the table. Apache Polaris became a top-level Apache project on 15 February 2026, and Unity Catalog OSS, which implements the Iceberg REST Catalog APIs, is an LF AI & Data sandbox project.
5. Test your exact tables. Run one write and one read from a second engine, including deletes, partition changes and views, before you commit a roadmap to it.

• Views are forgotten. Databricks states that external Iceberg engines cannot read Unity Catalog views, so a dashboard built on a view will not follow the table to another engine.
• Two catalogs, two permission models. A table registered in one catalog and exposed through another can end up governed by two sets of rules that disagree. Decide which catalog is the system of record for each table.
• Write paths are assumed, not tested. Reading from a second engine is the easy half. Check that the writes you need, such as deletes and merges, are among those the platform supports.
• Storage details are overlooked. Databricks lists credential vending as unsupported on workspaces that use default storage, and Snowflake bills egress when an external engine reads Snowflake-managed storage from another region or cloud.

Either format leaves table care to someone: compacting small files, expiring old snapshots or vacuuming unreferenced files, and keeping statistics useful. Platforms automate some of it, and Databricks documents that Unity Catalog handles snapshot expiration and compaction for managed Iceberg tables. On a platform you run yourself, those become scheduled jobs you own, and an expiry job set too tight removes the history you wanted. AceMQ supports Apache Spark and Starburst and Trino estates and scopes table-format and catalog design as consulting.

• Apache Iceberg in Databricks (last updated 2 November 2026)
• Snowflake: Apache Iceberg tables (checked 4 November 2026)
• Apache Iceberg documentation
• Delta Lake
• Databricks UniForm
• Apache Polaris
• Unity Catalog OSS