Apache Iceberg version 3 is now generally available on both of the two platforms that matter most to lakehouse buyers. Snowflake shipped v3 support on May 7, 2026 (Snowflake, 2026). Databricks Runtime 18.0 followed with its own Iceberg v3 support, after a public preview earlier in the year (Databricks, 2026). For the first time, the format war that has shaped data platform purchasing for the last three years has a settled answer on the table format itself. What is not settled is who controls access to it.
What a table format actually does
A table format is the metadata layer that sits between raw files in cloud storage and the query engines that read them. Before formats like Iceberg, Delta Lake and Hudi existed, a "table" in a data lake was really just a folder of Parquet or ORC files, with no shared record of which files were current, no atomic commits, and no safe way for two engines to write to the same data at once.
Iceberg, originally built at Netflix and now an Apache Software Foundation project, solves that by keeping a versioned manifest of every file that belongs to a table. Any engine that speaks the Iceberg specification, Snowflake, Databricks, Spark, Trino, Flink, or a warehouse from AWS or Google, can read and write the same physical data without copying it. That is the pitch: one copy of the data, many engines, no proprietary lock-in to a single vendor's storage layer.
Delta Lake, created by Databricks, and Apache Hudi solve a similar problem with different tradeoffs. All three are open source. The practical difference in 2026 is adoption: Iceberg is the format every major cloud data platform now reads and writes natively, while Delta remains the default and best-optimized format inside Databricks itself.
What v3 adds
The v3 specification was finalized after roughly four years of community work. It adds seven capabilities on top of v2: deletion vectors, row-level lineage, a native VARIANT type for semi-structured data, default column values, geometry and geography types, nanosecond-precision timestamps, and multi-argument partition transforms (Snowflake, 2026).
Deletion vectors are the change most likely to affect a running production system. Instead of rewriting entire data files to process an update or delete, the engine can mark individual rows as deleted in a small companion file. Snowflake's own documentation describes this as a way to speed up update and delete operations on Iceberg tables (Snowflake, 2026). Row-level lineage matters for teams building change-data-capture pipelines on top of Iceberg tables rather than a proprietary CDC feature, since it gives a standard way to track which row changed and when, independent of the engine that made the change.
On Databricks, Unity Catalog-managed Iceberg v3 tables now support the same deletion vectors, row lineage, and VARIANT type, and Databricks Runtime 18.0 runs on Apache Spark 4.1.0 (Databricks, 2026).
Storage and the catalog fight
Snowflake also made a second move that is arguably more consequential than the spec update. On June 1, 2026, Snowflake Storage for Apache Iceberg tables reached general availability, letting Snowflake store and manage Iceberg data and metadata files directly, without a customer configuring an external S3 bucket or IAM role first (Snowflake, 2026). That removes one of the standing objections to Iceberg on Snowflake: the extra setup work of managing external volumes.
Underneath the format itself sits a second, less visible standard: the catalog that tracks where tables live and who can access them. This is where the two platforms diverge. Apache Polaris, the open source Iceberg catalog Snowflake built and contributed to the Apache Software Foundation, graduated to a top-level Apache project on February 19, 2026. The project spent roughly 18 months in incubation, with around 100 contributors and more than 2,800 merged pull requests (Apache Polaris, 2026). Snowflake's Horizon Catalog now runs on Polaris and supports bidirectional read and write access between Snowflake-managed Iceberg tables and outside engines through the Iceberg REST Catalog API.
Databricks takes a different approach with Unity Catalog. Unity Catalog implements the Iceberg REST Catalog specification as a server, meaning external engines can read tables registered in Unity Catalog, but it does not act as a client against other REST catalogs, so the access is effectively one-directional. That distinction matters more than it sounds: a team standardizing on Unity Catalog can be read from elsewhere but has a narrower path to reading other vendors' Iceberg catalogs from inside Databricks.
What to check before committing to a format
For a team choosing or re-evaluating its lakehouse stack this year, four questions cover most of what matters.
Which catalog controls the table, not just which format stores it. The table format is now largely interoperable. The catalog, Polaris, Unity Catalog, AWS Glue, or another Iceberg REST implementation, decides how portable that table actually is across engines.
Whether writes, not just reads, work across engines. Several platforms support reading another vendor's Iceberg tables well before they support writing to them. Check both directions before assuming full interoperability.
Whether the engine's query optimizer is tuned for the format. Databricks' Photon engine still runs faster against native Delta tables than against externally managed Iceberg tables in several published benchmarks, a gap attributed to Parquet layout and I/O optimizations specific to Delta. Vendor benchmarks on this point should be treated as directional, since every publisher of a performance comparison has a stake in the result.
What migration actually costs. Moving from Delta or Hudi to Iceberg, or from one Iceberg catalog to another, involves rewriting metadata at minimum and sometimes rewriting data files. Get a concrete estimate before assuming an open format means a free move.
What commonly goes wrong
Teams that adopt Iceberg expecting immediate vendor independence are often surprised by how much the catalog choice still constrains them. An open table format does not guarantee an open catalog, and the catalog is what most engines actually talk to. The second common mistake is comparing table format benchmarks without checking who ran them and on what workload. File sizing, compaction settings, and partition strategy all move the numbers by a wide margin, and a benchmark published by a vendor selling one of the two formats compared should be read with that in mind.
Sources
- Snowflake Release Notes, "Apache Iceberg v3 general availability" (May 7, 2026) - https://docs.snowflake.com/en/release-notes/2026/other/2026-05-07-iceberg-v3-ga
- Snowflake Release Notes, "Snowflake Storage for Apache Iceberg tables general availability" (June 1, 2026) - https://docs.snowflake.com/en/release-notes/2026/other/2026-06-01-iceberg-snowflake-storage-ga
- Databricks Blog, "The Next Era of the Open Lakehouse: Apache Iceberg v3" - https://www.databricks.com/blog/next-era-open-lakehouse-apache-icebergtm-v3-public-preview-databricks
- Databricks Documentation, Release Notes for Runtime 18.0 - https://docs.databricks.com/aws/en/release-notes/runtime/18.0
- Apache Polaris Project Blog, "Apache Polaris Graduates to Top-Level Project" (February 19, 2026) - https://polaris.apache.org/blog/2026/02/19/apache-polaris-graduates-to-top-level-project/