Apache Iceberg's v4 specification is being designed around a single theme: eliminating unnecessary work per operation. Key proposals include single-file commits via a Root Manifest to reduce commit amplification, snapshot offloading, delta-encoded schemas, and efficient column updates for wide AI feature/embedding tables. Two features are already ratified into v4: Content Stats, a columnar replacement for per-file statistics that allows projecting only needed columns during query planning, and relative paths, which let tables be relocated by updating only the catalog root pointer instead of rewriting every file path. Iceberg 1.11.0, released May 2026, fully implements the v3 spec with deletion vectors, the VARIANT type, and row lineage, and Dremio recommends adopting v3 now since many v4 proposals build directly on those foundations.
Table of contents
Making Commits Cost What They ShouldData Writes Are Also Getting an UpdateMaking Metadata Cheaper to ReadWhat Iceberg Users Should Do NowTry Dremio Cloud free for 30 daysQuestions this post answers
What ratified features are part of the Apache Iceberg v4 spec so far?
Two features have been ratified into the Iceberg v4 spec: Content Stats, ratified in May 2026, and relative paths. Content Stats replaces binary blob statistics maps in Avro manifests with a typed, columnar representation so query engines can read bounds for only the columns they need. Relative paths store file references relative to the table root instead of as absolute URIs, so relocating a table only requires updating the catalog's root pointer. Track evolving Iceberg v4 features and specs on daily.dev as the lakehouse ecosystem shifts.
How does the proposed single-file commit feature reduce commit amplification in Apache Iceberg?
The single-file commits proposal introduces a Root Manifest that replaces the manifest list and can inline small changes directly into itself, so a small commit writes one file instead of four. Background maintenance later rebalances those inlined entries into leaf manifests, keeping planning fast on large tables while letting a streaming table's tree stay shallow near the root for cheap commits. Engineers weighing lakehouse write costs can follow Iceberg commit design changes on daily.dev.
How does Apache Iceberg plan to make column updates more efficient for wide AI feature tables?
The efficient column updates proposal lets Iceberg write only the changed columns to new files instead of rewriting entire rows, then stitches those files together with the base file at read time. This targets AI workloads like feature tables and embedding tables that can be hundreds of columns wide, where updating a handful of columns currently forces a full row rewrite. Teams building AI feature stores on Iceberg can follow this proposal's progress via daily.dev.