Guide, 9 min read, updated 13 October 2026

Apache Iceberg v3, explained for analysts and data engineers

Iceberg has become the open table format behind modern data platforms. Version 3 makes updates faster, tracks every row and handles JSON natively. Here is what it means for you.

SnowflakeDatabasesData modelling
All guides and cheat sheets

If you work with Snowflake, Databricks, BigQuery or a data lake, you have probably heard of Apache Iceberg. It has become the standard open format for storing analytical tables in cloud storage, so that many different tools can read and write the same data. In 2026, version 3 of the Iceberg table format became available in the major platforms. Here is what Iceberg is, what v3 adds, and how to decide when to move.

Iceberg in one paragraph

An Iceberg table is a set of Parquet files plus metadata that records which files make up the table at each point in time. That metadata gives plain files the features of a database table: safe concurrent writes, schema changes, time travel to earlier versions, and fast filtering. Because the format is open, Snowflake, Databricks, Spark, Trino, DuckDB, pandas and others can all work on the same table, without copying data between systems. That is the main reason it appears in almost every modern data stack conversation.

What v3 adds

Deletion vectors: much faster updates and deletes

Changing a few rows in a big table used to create many small "delete files" that slowed down every later read. v3 replaces them with compact deletion vectors, bitmaps that mark which rows are gone. Vendors report updates and deletes up to 10 times faster, and reads stay quick after frequent changes. This matters most for tables updated by CDC (change data capture) and MERGE statements.

Row lineage: every row has an identity

v3 tables can track a stable ID for each row and the version in which it last changed. Downstream jobs can then pick up exactly the rows that changed since their last run, which makes incremental models simpler and cheaper, without extra tooling.

VARIANT: JSON as a first-class column

Semi-structured data such as API responses and event payloads can be stored in a native VARIANT column, stored efficiently so that queries on a few fields do not read the whole document. The same idea is arriving in engines such as DuckDB 2.0, so the format and the tools now line up.

Smaller improvements that remove real pain

  • Default values for new columns: add a column with a default and old files simply read with that value, with no expensive backfill.
  • Nanosecond timestamps for event and financial data.
  • Geospatial types (geometry and geography) with efficient filtering by area.
  • Partitioning on several columns at once, for more flexible table layouts.

Who supports v3 in 2026

  • Snowflake: v3 features became generally available in May 2026. New tables still default to v2, so you opt in to v3.
  • Databricks: generally available on Databricks Runtime 18.0 and later, with Unity Catalog.
  • Apache Spark: Spark 4.0 is the reference implementation; Spark 3.5 has partial support.
  • Trino and some other engines were still catching up in mid-2026, so check the current release notes.
  • Python and local tools: pandas 3.0 can read and write Iceberg with pd.read_iceberg() and to_iceberg(), and dbt v2 supports Iceberg catalogs, including with DuckDB.

Should you upgrade your tables?

The key rule: v3 readers can read v2 tables, but v2 readers cannot read v3 tables, and upgrading a table is generally one-way. Before moving a table to v3:

  • List every tool that reads the table, including BI tools, notebooks and other teams' jobs, and confirm each supports v3.
  • Start with new tables that benefit most: frequently updated tables, CDC targets and JSON-heavy event data.
  • Keep stable, rarely changed tables on v2 until every engine you use is ready. There is no prize for upgrading early.
  • Test on a copy and compare query times and costs before and after.

What it means for analysts

Most of the time, nothing changes in how you write SQL: you query an Iceberg table like any other table. What improves is what happens underneath: fresher data from faster updates, cheaper incremental models, and JSON you can query efficiently. Knowing the basics helps you ask the right questions when your data team plans a migration.

For the modelling side, see Star schema data modelling and Getting started with Snowflake.

Sources: the Apache Iceberg specification, Databricks' "Apache Iceberg v3: Moving the Ecosystem Towards Unification" and Atlan's Iceberg v3 guide for Snowflake. Engine support changes quickly, so check each vendor's documentation before upgrading tables.

Alessandro Ecclesie AgazziWritten by Alessandro Ecclesie Agazzi, analytics engineer in London. Updated 13 October 2026. About me