Iceberg v3 outran the engines that read it

For once the story is not the format war; Iceberg won that argument. The story is version skew inside the winner. The v3 spec, ratified in mid-2025, spent this spring going GA on the write side: Dremio in April, Snowflake on May 7, Databricks' Unity Catalog on May 28. The read side is another matter, and the read side is where your dashboards live.

What v3 actually adds

The additions are real, which makes the lag worth caring about. Binary deletion vectors let merge-on-read updates skip the rewrite storms that made heavy CDC on v2 tables an accounting problem. Row lineage attaches a persistent row id and a last-updated sequence number to every row, so change capture becomes metadata instead of snapshot diffing. A variant type gives semi-structured data a standard representation; column default values and new geometry, geography and nanosecond-timestamp types round it out, per Google's tour of the spec and Snowflake's release notes. On the library side, Apache Iceberg 1.11.0 carries the reference implementation.

Read the list twice and a pattern appears: these are the conveniences Delta always kept engine-side, now standardized. Databricks says as much in its own unification pitch.

The support matrix, August 2026

Snowflake's GA covers deletion vectors, row lineage, variant and default values, with one caveat worth reading slowly: external engines can read its managed v3 tables through the Horizon REST catalog, but external writes are not supported. Databricks ships deletion vectors, row tracking and variant across managed, foreign and UniForm tables. Dremio's release covers the same trio. AWS announced deletion vector and row lineage support in November across EMR, Glue and S3 Tables; Athena is conspicuously not on that list.

Then the queue. Trino is a fork in the road: Starburst's own v3 guide walks deletion vectors and row lineage in its commercial platform, while a readiness review from December found open-source Trino without v3 support at all, concluding that if Trino is a major engine in your stack, adoption will most likely need to wait. Athena has no v3 support. BigQuery exposes v1 and v2 only. None of this is obscure; it is just absent from the launch posts.

The mechanics of the skew are unforgiving. A format version is not a feature flag. The moment a writer commits deletion vectors to a table, a v2-only reader does not degrade gracefully; it declines the table. Which means the version you can actually run is set by the slowest engine in your read path, not the shiniest one in your write path.

Verdict

If your write and read paths live inside one platform, adopt. The features are the point: less compaction babysitting, cheaper CDC, and the vendor has already done the interop with itself. Snowflake-only and Databricks-only shops have little reason to wait.

If your fleet is mixed, and the entire sales pitch of an open table format was that your fleet could be mixed, check the matrix before flipping the table version. A lakehouse with Athena or BigQuery in the read path is a v2 lakehouse for now, whatever the writer supports. Wait, not because v3 is immature, but because your readers are.

The promise of an open format was that tables would outlive any single engine's roadmap. True, it turns out, in both directions: the standard now advances faster than most engines implement it. Open is the format. Open is also the queue.