Why Iceberg v3 Marks the “iPhone Moment” for Data Lakehouses

On March 4, 2026 Snowflake announced public preview support for Apache Iceberg v3, followed a month later by Databricks, confirming that the four major lakehouse vendors (Databricks, Snowflake, Google, Dremio) are fully backing Iceberg v3. The specification, approved in June 2025, is presented as a transformative shift rather than a routine version bump.

1. Deletion Vectors: Solving Row‑Level Update Performance

Problem in v2

Iceberg v2 added row‑level deletes via positional delete files, but each delete generated a separate small file. Queries had to match, merge, and filter these files, causing a performance bottleneck that grew with frequent updates, making write‑heavy tables slower to read.

v3 Solution

v3 introduces binary deletion vectors stored as Roaring Bitmaps attached to each data file. A bitmap bit of 0 means the row is valid, 1 means deleted.

No more thousands of tiny delete files; all delete information is compressed into a compact bitmap stored alongside the data file (typically in a .puffin file).

Queries read the bitmap together with the data file and skip deleted rows with a single bitwise operation, eliminating the "snow‑clearing" overhead.

Write amplification is dramatically reduced because updating a few rows only requires updating the bitmap, not rewriting entire data files.

Databricks reports that deletion‑vector processing is ten times faster than the traditional copy‑on‑write approach, and v3 mandates a single deletion vector per file, preventing a resurgence of small‑file problems.

2. Row Lineage: Making CDC a Native Table Property

Problem in earlier formats

Determining which rows changed since the last query required manual timestamp columns, watermarks, full‑table comparisons, or external CDC tools, all of which are heavy, fragile, or costly.

v3 Solution

Iceberg v3 adds two metadata fields to every row: a globally unique Row ID and a Sequence Number that records the last commit version affecting the row. These fields are part of the table format and must be maintained by any writing engine.

Consequently, identifying changed rows reduces to a simple metadata query comparing sequence numbers between snapshots, eliminating full scans and external tooling.

Together, row lineage and deletion vectors make CDC a native property of the table itself.

With row‑level lineage, incremental materialized view refreshes become trivial, turning a potential 30‑minute job on petabyte‑scale data into a 10‑second operation. AI engineers can also trace the provenance of training data directly, supporting data‑quality audits and model compliance.

3. VARIANT Type: First‑Class Support for Semi‑Structured Data

Problem with JSON in v2

Half of real‑world data is semi‑structured. Prior approaches either flattened JSON into wide tables (creating hundreds of columns with many nulls) or stored JSON as strings (losing columnar performance and predicate push‑down).

v3 Solution

Iceberg v3 introduces a native VARIANT data type with an efficient binary encoding that preserves schema flexibility while enabling columnar optimizations:

Predicate push‑down on nested fields (e.g., WHERE payload.event_type = 'purchase') occurs during file scanning without full JSON parsing.

Shredding optimizes frequently accessed fields into separate columnar storage, achieving near‑native column performance.

Zero‑schema‑migration: new fields can be added without ALTER TABLE, written and queried directly.

CREATE TABLE events (
    event_id BIGINT,
    ts TIMESTAMP_NS,
    payload VARIANT
) USING iceberg
TBLPROPERTIES ('format-version' = '3');

SELECT payload:user_id, payload:action, payload:metadata:device_type
FROM events
WHERE payload:action = 'purchase'
  AND ts > current_timestamp() - INTERVAL 1 HOUR;

The VARIANT type lets engineers store raw logs, LLM inference traces, or agent call records directly in the lake and query them with standard SQL, accelerating analytics by an order of magnitude.

4. Default Column Values: Schema Evolution in Sub‑Second Time

Previously adding a column with a default value to a billion‑row table required rewriting all data files, consuming hours and risking service disruption.

v3’s default column value feature makes this a pure metadata operation. The column definition is stored in the table schema, and when a query encounters a missing column value, the engine fills in the default instantly.

ALTER TABLE orders ADD COLUMN priority STRING DEFAULT 'normal';

The operation completes in sub‑second time because no data files are touched.

5. Nanosecond‑Precision Timestamps: The Final Mile of Accuracy

v3 adds timestamp_ns and timestamptz_ns types, extending precision from microseconds to nanoseconds.

High‑frequency trading: order‑book events can occur at nanosecond intervals, where microsecond granularity would lose ordering.

IoT sensors: industrial devices may sample at megahertz rates.

Distributed‑system debugging: nanosecond timestamps are essential for reconstructing causal chains and diagnosing race conditions.

Earlier, these scenarios required storing nanosecond values in BIGINT, losing type semantics and query convenience. v3 restores true timestamp semantics at nanosecond resolution.

6. Industry Response

Beyond technical merits, the rapid ecosystem response signals a decisive shift:

Databricks supports all v3 features and announces interoperability with Delta Lake via UniForm, allowing a single write to be read by Snowflake, BigQuery, Redshift, etc.

Snowflake entered public preview for Iceberg v3 in March 2026, adding managed tables and external directory support while advancing Apache Polaris governance.

Google Cloud’s BigLake (BigQuery Managed Iceberg) fully implements v3, with Google engineers contributing to the spec.

Dremio published a detailed technical walkthrough on the day the v3 spec was approved.

With all four major lakehouse engines fully backing Iceberg v3, the format war is effectively over; Iceberg has moved from a candidate standard to the de facto standard.

7. Conclusion

Iceberg v3 is not a routine feature add‑on; it is the watershed that turns the data lakehouse from a viable concept into a mature architecture. Deletion vectors deliver ten‑fold faster row‑level updates, row lineage makes CDC native, VARIANT elevates semi‑structured data, default column values shrink schema‑change latency to seconds, and nanosecond timestamps fill the last precision gap, all while gaining unanimous industry endorsement.