Vendor blogs will tell you a feature is coming. Conference keynotes will tell you a feature is exciting. The Apache Iceberg dev mailing list tells you what is actually settled, what is genuinely contested, and which design questions keep smart people arguing at 11 PM across time zones.
The gap between the marketing version of Iceberg v4 and the mailing list version is exactly the gap between a story and the truth. Let’s close that gap.
The Honest Status: v4 is Not Released
Let’s set expectations before we get into the fun parts. Iceberg v4 is not released. There is no v4 spec you can set on a table today. The current stable line is the 1.11 release from May 2026, and that release sits firmly in the v3 era, with v3 features like variant shredding and deletion vectors as the production-grade capabilities you should actually be building on.
Treat v3 as the production target and v4 as the horizon worth watching.
What has changed is how concrete that horizon has become. V4 stopped being a wish list some time ago, and over the past two months it crossed another threshold: pieces of it are now formally ratified spec text. In May 2026, the community voted to add relative path support to the v4 spec. In the same window, a vote passed adding the new Content Stats representation. In early June, the community voted to add a draft spec for a new compact bitmap format. These are not blog posts or design docs anymore. They are the spec, decided in public votes with recorded results.
What’s Already Decided: The Concrete Wins
Relative Paths: The Unsexy Operational Savior
Iceberg has always stored absolute paths. Every manifest and metadata file embeds full URIs down to the bucket and region. This meant that moving a table, for disaster recovery, region migration, or cloning into a test environment, required rewriting every path in the metadata tree. For big tables, that rewrite was a project, not an operation.
The v4 answer stores paths relative to a table root, with the catalog supplying the root location. Move the directory tree, update the catalog, done. Daniel Weeks brought it to a formal vote in mid-May 2026, and it passed. The spec’s language around table location already reads in terms of “v4 and later.”
This will be one of those features nobody writes excited blog posts about in three years, because it will have quietly deleted a whole category of operational pain. Those are often the best features.
Content Stats: The New Shape of Statistics
This one is less visible and more consequential. In May 2026, Eduard Tudenhöfner brought the Content Stats representation to a vote, and the community adopted it into v4.
Here is the problem it solves. Today, per-file column statistics live in generic maps keyed by field ID. The values are serialized binary blobs. This design has three weaknesses:
- Wide tables carry enormous maps, row-oriented Avro forces engines to deserialize all of it even when planning needs bounds for exactly one column
- Serialization loses type context, creates subtle hazards as schemas evolve
- The map structure cannot express richer metadata, locks out index structures and sketches
Content Stats replaces the maps with a typed, structured representation. Statistics become real structured data, projectable field by field. You can read the lower bounds for three columns without touching stats for the other two hundred.
The dev list already carries a follow-on thread on aggregate column stats for v4, exploring table-level and manifest-level aggregations layered on the new representation. Statistics are becoming first-class data, and first-class data grows capabilities.
The Headline Fight: Single-File Commits and the Adaptive Metadata Tree
This is the proposal that anchors v4, and where the dev list is liveliest in July 2026.
The problem: every Iceberg commit today writes a new metadata JSON, a new manifest list, and at least one new manifest, even when the commit adds a single small data file. For streaming jobs committing every few seconds, the metadata writing dominates the work, and compaction jobs end up fighting the ingestion they exist to support.
The proposed cure restructures the tree around a Root Manifest that replaces the manifest list. Small changes can be inlined directly into it. A tiny streaming commit writes one file instead of a cascade. As inlined entries accumulate, background maintenance rebalances them down into leaf manifests.
The design is called adaptive because the tree’s shape follows the workload: hot streaming tables keep recent writes near the root for cheap commits, batch tables settle into the classic layered shape.
The Partition Tuple Question
The question generating the most traffic: what happens to the partition tuple? In the current format, every manifest entry carries a tuple of partition values. The v4 tree wants to break that coupling. Ryan Blue opened a dedicated thread exploring a striking option: eliminating the stored tuple entirely and reconstructing partition information from column bounds.
The complication? String and binary columns can have truncated bounds in stats, which breaks the reconstruction trick for identity-partitioned string columns. Every option trades something. Keeping the tuple keeps coupling. Reconstructing from bounds demands exactness guarantees. This is exactly the kind of question that looks tiny from the outside and determines the shape of the format from the inside.
None of this reads like a proposal in trouble. It reads like a proposal being taken seriously. The write path and the read path are being priced against each other in the open, workload by workload, before anyone votes.
The Hottest Thread: Efficient Column Updates
If you sort the spring dev list by message volume, one discussion towers over the rest: efficient column updates. It has drawn more replies than any v4 thread.
The problem is the wide-table workload that AI teams live in. Picture a feature table with hundreds of columns or an embedding table with large vectors, updated by jobs that recompute a handful of columns. Iceberg today offers no way to update a column without rewriting entire rows. Refresh one embedding column and you rewrite two hundred columns of untouched data alongside it.
The proposal introduces column update files: write only the changed columns to new files, leave base files untouched, and stitch the two together at read time.
The reason the thread runs to dozens of messages is a real architectural argument. One camp asks whether this belongs in Iceberg at all or whether Parquet should solve it. The counterargument is that a column-to-file mapping inside Parquet duplicates what manifests already do, putting a second bookkeeping system inside the first. Contributors have brought comparative notes on how Lance, Hudi, and Paimon approach column groups.
My read as of July: the workload pressure is undeniable, but the layering question is the least settled major design question in v4.
Deletes Keep Evolving
V3’s deletion vectors were a big win. The v4 conversation shows the community sharpening that work along two lines.
Compact Bitmaps
Ryan Blue opened a discussion proposing a new bitmap serialization, and by early June the community voted to add a draft bitmap spec to the repository. The motivation is to make the bitmap structures behind deletion vectors leaner and more broadly useful.
The Equality Delete Squeeze
Equality deletes remain the write-cheap tool that streaming CDC writers rely on, and they remain expensive for readers. A thread on Flink converting equality deletes to deletion vectors has been working through how to resolve them closer to write time.
The timing is not accidental. Maximilian Michels reported that the Flink equality delete to deletion vector conversion work is now complete, merged across six commits. The feature ships as ConvertEqualityDeletes, integrated with IcebergSink. This is the workable alternative that was missing in 2024.
Meanwhile, a formal push has emerged to deprecate equality deletes from the v4 spec entirely. The V4 question is whether the format still needs them once conversion tooling makes positional deletes cheap enough for streaming workloads.
Does v4 Make v3 Adoption a Waste?
The opposite. Several v4 proposals are direct extensions of v3 features. Running v3 now positions you for them:
- Deletion vectors are the foundation the compact bitmap work refines
- Row lineage is the foundation the row timestamp proposal builds on
- The variant type is a major consumer of the new content stats representation
Teams that adopt v3 features today are learning the operational patterns that v4 assumes as background. Waiting on v4 while ignoring v3 gets you the worst of both timelines.
The Convergence Question: Databricks and Delta Lake
Databricks proposed that Delta Lake 5.0 adopt the Iceberg v4 metadata tree as its native content metadata. The technical claim is that the two formats already converged on the same ideas, and maintaining two encodings serves nobody.
What the past six weeks have clarified: the convergence story rides on top of the v4 design process. It does not drive it. The threads on partition tuples, root manifest scan costs, and snapshot offloading are being argued on their engineering merits by contributors from many companies. Whether Delta 5.0 ultimately adopts the resulting tree is a Delta decision. Whether the tree is good is an Iceberg community decision.
Treat convergence as a direction to watch, not a plan to build on. The thing to actually build on is the v4 work itself.
The Bigger Picture: Three Forces Reshaping Iceberg
Step back from the individual threads and v4 resolves into one picture with three panels:
Commit economics: Single-file commits, the root manifest, snapshot offloading, and delta-encoded schemas all attack the invariant that today, the cost of committing scales with the size of the table’s metadata rather than the size of the change.
Metadata as data: Content stats, aggregate stats, and Parquet manifests treat metadata as structured, typed, columnar information. Richer metadata that stays cheap to read makes planning possible at extreme width and opens the door to the index structures that AI retrieval workloads need.
Granularity of change: Deletion vectors gave us row-level change without file rewrites in v3. Column update files aim for column-level change in v4. Relative paths give table-level relocation without metadata rewrites. In each case the format learns to express a smaller unit of change.
This evolution in data infrastructure is part of a broader trend toward unified transactional and analytical architecture on open table formats, where the boundaries between OLTP, OLAP, and real-time streaming continue to dissolve.
What Practitioners Should Do in July 2026
-
Run v3 and actually use it. The 1.11 line is current. I still meet teams debating v4 timelines who have not turned on deletion vectors. Harvest the fruit that is ripe.
-
Track the threads that map to your pain. Streaming teams should follow single-file commits and snapshot offloading. AI platform teams should follow efficient column updates and the stats work. Multi-region operators should note that relative paths are now ratified.
-
Learn to read the list yourself. The archives at lists.apache.org are public. An hour a month skimming subjects will keep you ahead of every secondhand summary.
-
Discount predictions about timing. Nobody serious has committed a ship date. Specs ship after the arguments resolve. What you can bank on is the direction, because the direction is now backed by votes.
The reason any of this is worth your attention is that it happens in the open, under governance no single vendor controls, with ratification by public vote. That is why an Iceberg table you write today will be readable by engines that do not exist yet, and it is why the arguments are slow.
The slowness is the feature. It is what makes the result safe to build a decade on.
