Cross-posted. This article's canonical home is iceberglakehouse.com.

The State of Apache Iceberg v4 in July 2026: What the Dev List Tells Us About the Format's Next Chapter

By Alex Merced, Head of Developer Relations at Dremio

If you want to know where Apache Iceberg is headed, do not read the press releases. Read the dev mailing list.

I say that as someone who reads it every week. Vendor blogs will tell you a feature is coming. Conference keynotes will tell you a feature is exciting. The dev list tells you what is actually settled, what is genuinely contested, and which design questions keep smart people arguing at 11pm across time zones. The gap between the marketing version of Iceberg v4 and the mailing list version of Iceberg v4 is exactly the gap between a story and the truth.

So this article is my mid-2026 checkpoint on v4, grounded in what the community has voted on, what it is actively debating, and what has quietly changed since Iceberg Summit in April put v4 on every conference slide. I wrote a broad v4 overview in June. This piece goes deeper on where things stand right now, in July, with the dev list as the primary source. My goal, as always, is to make the logic of these proposals accessible. You should finish this article able to explain not just what v4 proposes, but why each piece exists and what problem forced it into existence.

First, the Honest Status

Let me 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. The practical guidance I gave in June has not changed one bit: treat v3 as the production target and v4 as the horizon worth watching.

What has changed is how concrete the 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 to v4, the typed and structured replacement for the old column statistics maps. In early June, the community voted to add a draft spec for a new compact bitmap format to the repository. These are not blog posts or design docs anymore. They are the spec, or drafts formally adopted into the spec process, decided in public votes with recorded results.

So the accurate picture of v4 in July 2026 is a spectrum. On one end sit ratified pieces like relative paths and content stats. In the middle sit heavily developed proposals with active design syncs, like the adaptive metadata tree and single-file commits. On the other end sit live arguments that could still go several directions, like the exact fate of the partition tuple and where column-level updates should live. Walking that spectrum, from settled to contested, is the plan for the rest of this article.

How a Proposal Becomes Spec: Reading the Process Itself

Before touring the proposals, it helps to know the machinery they move through, because the machinery is how you judge maturity. Iceberg design work follows a recognizable lifecycle, and once you can spot the stages, the dev list stops looking like noise and starts looking like a status board.

Ideas enter as a DISCUSS thread, usually paired with a design document and often a GitHub issue or an Iceberg Enhancement Proposal. This stage can run weeks or months, and message volume here signals contested design space, not trouble. The efficient column updates thread has drawn more than fifty messages precisely because the question is worth arguing.

Serious proposals then grow supporting structure. Recurring community syncs get scheduled, with recordings and written summaries posted back to the list so nothing is decided in a room. The single-file commits work runs on this cadence today, with syncs organized and summarized publicly, appendices added to the design doc as options get mapped, and specific contributors owning specific open questions. When you see meeting summaries and change-detection diagrams landing on a thread, you are watching a proposal in its engineering phase.

The finish line is a VOTE thread. A committer proposes specific spec text, the community votes in public over a defined window, and the result gets recorded. That is what happened with relative paths in May, with the content stats representation the same month, and with the draft bitmap spec in June. Vote threads are short and undramatic on purpose. By the time text reaches a vote, the arguments already happened.

Two reading tips follow from this. First, weigh spec text and vote results above everything else, including design docs, because docs describe intentions and votes record decisions. Second, calibrate on who is in a thread. When you see the same design question drawing sustained engagement from engineers at half a dozen competing companies, the outcome will bind all of them, which is exactly what makes it trustworthy. A quiet thread with one company's engineers talking to themselves is a signal of a different kind.

With the machinery in view, the tour that follows is organized by lifecycle stage: ratified first, engineering phase second, open arguments third.

A Ninety-Second Refresher on the Metadata Tree

Every v4 proposal is a change to Iceberg's metadata, so we need the current model in our heads. If you know it cold, skip ahead.

An Iceberg table is a tree of files. At the bottom sit data files, usually Parquet, holding the rows. Above them sit manifest files, which list groups of data files along with per-file statistics like row counts and column min and max values. Above those sits a manifest list, one per snapshot, collecting all the manifests that make up one consistent version of the table. At the top sits a metadata file written as JSON, which records the schema, partition specs, sort orders, snapshot history, and a pointer to the current snapshot. A catalog holds the pointer to the current metadata file, and commits happen by atomically swapping that pointer.

This tree is why Iceberg works. Query planning reads metadata instead of listing storage. Statistics let engines skip files that cannot match a filter. Snapshots give you time travel and isolation. The design has carried tables to tens of petabytes.

The design also carries assumptions from the era that produced it. It assumes commits are relatively infrequent, so it is acceptable that every commit writes a new metadata JSON, a new manifest list, and new manifests. It assumes tables are modest in width, so it is acceptable that statistics live in generic maps inside row-oriented Avro files. It assumes tables rarely move, so it is acceptable that every file reference is an absolute URI with the bucket baked in. Streaming workloads broke the first assumption. AI feature tables broke the second. Multi-region operations broke the third. V4 is the format renegotiating all three assumptions at once, and the dev list is where the negotiation happens.

What Is Already Decided: Relative Paths

Start with the most settled item, since it shows what the finish line looks like.

Iceberg has always stored absolute paths. Every manifest and metadata file embeds full URIs down to the bucket and region. This was a defensible early choice that prevented ambiguity on eventually consistent object stores. It also 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. The internal relationships never change, so nothing needs rewriting. Absolute paths remain legal for references that genuinely live outside the table root.

The dev list history here is instructive. The proposal thread ran for months, working through edge cases like mixed absolute and relative references, how imported files behave, and what writers must guarantee. Then 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." When people ask me how Apache governance actually functions, this thread is my answer: a proposal, months of public argument, a refined design, a vote, and then spec text that every vendor implements from the same document.

Relative paths 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.

Also Decided: Content Stats, the New Shape of Statistics

The second ratified piece 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: one map for lower bounds, one for upper bounds, one for null counts, and so on. The values are serialized binary blobs. This design has three weaknesses that get worse every year. Wide tables carry enormous maps, and row-oriented Avro forces engines to deserialize all of it even when planning needs bounds for exactly one column. Serialization loses type context, which creates subtle hazards as schemas evolve. And the map structure cannot express anything richer than a scalar per column, which locks out entire categories of useful metadata.

Content Stats replaces the maps with a typed, structured representation. Statistics become real structured data, with logical and physical types preserved, projectable field by field. You can read the lower bounds for three columns without touching stats for the other two hundred. The v3 spec already gestured in this direction for special cases, storing variant bounds as structured objects keyed by JSON path and geospatial bounds in dedicated structs. V4 makes that the general model rather than the exception.

The reason I call this consequential is what it makes possible downstream. A structured, extensible stats model can carry per-field metrics that the old maps never could: bounds for fields nested inside a variant, bounding boxes for geometry, and eventually the kinds of sketches and index structures that approximate nearest neighbor search needs. 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, so engines can answer questions like "roughly how many distinct values does this column hold" without scanning file-level stats at all. Statistics are becoming first-class data, and first-class data grows capabilities.

There is a companion proposal worth mentioning in the same breath: delta-encoded schemas. Every schema change in Iceberg today appends a complete copy of the schema to the metadata file. A wide table with a long evolution history drags hundreds of full schema copies around in its metadata JSON forever. The proposal stores schema changes as deltas against prior versions instead. It is a small idea aimed at the same disease: metadata bloat that grows with table width and table age. The thread is younger than the stats work, but it points the same direction.

The Headline Fight: Single-File Commits and the Adaptive Metadata Tree

Now we get to the proposal that anchors v4, and the one where the July 2026 dev list is liveliest.

The problem statement is easy to feel. 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 hourly batch jobs, nobody notices. For a streaming job committing every few seconds, the metadata writing dominates the work, small files pile up against storage prefixes until the object store throttles, and compaction jobs end up fighting the ingestion they exist to support. Write amplification is the tax, and streaming pays it at a punishing rate.

The proposed cure restructures the tree around a Root Manifest that replaces the manifest list and becomes the single entry point for a snapshot. The hierarchy flattens. And the root gains a critical new ability: small changes can be inlined directly into it. A tiny streaming commit writes one file, the new root, rather than a cascade of metadata files. As inlined entries accumulate, background maintenance rebalances them down into leaf manifests, restoring the layered structure that makes planning fast on huge tables. 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.

That is the elevator version. The dev list version, as of this summer, is a set of hard, specific engineering questions being worked in public, with recurring design syncs that Amogh Jahagirdar has been organizing and summarizing back to the list.

The question that has generated the most traffic lately is deceptively narrow: what happens to the partition tuple? In the current format, every manifest entry carries a tuple of partition values, and every manifest is bound to a single partition spec. The v4 tree wants to break that coupling, so a root can reference files spanning multiple partition specs and metadata can cluster in whatever way serves reads best. Ryan Blue opened a dedicated thread on partition tuples in v4, and the discussion has explored a striking option: eliminating the stored tuple entirely and reconstructing partition information from column bounds, using the property that a file is effectively partitioned on a field when that field's lower and upper bounds are equal.

The complication, and the reason the thread runs long, is the edge cases. String and binary columns can have truncated bounds in stats, which breaks the reconstruction trick for identity-partitioned string columns unless writers are required to keep exact bounds for them. And the main consumer of partition tuples turns out to be equality delete matching, which raises a further option discussed in the thread: make v4 equality deletes global and scope their application by stats rather than by partition. Every option trades something. Keeping the tuple keeps coupling. Reconstructing from bounds demands exactness guarantees. Going global on equality deletes changes delete semantics. This is exactly the kind of question that looks tiny from the outside and determines the shape of the format from the inside.

The other pressure point is read cost. Inlined entries near the root are wonderful for writers and a new burden for readers, who must scan them during planning. List participants have pushed hard on this: does the spec accept a linear scan of inlined entries as the price of write throughput, and what happens to a REST catalog that has to partially decode hundreds of inlined entries per planning request under high concurrency? Push too much work to the catalog and you risk turning it into a small query engine. Flush entries to leaves too eagerly and you resurrect the small-file storm that single-file commits were built to end. The change-detection work, mapping how incremental readers detect what changed between snapshots in the new tree across a variety of write scenarios, has its own section in the design doc with diagrams contributed by Steven Wu, and the group is verifying those cases methodically.

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 result will be better for the arguing.

The Quieter Metadata Question: What Happens to metadata.json?

Alongside the tree redesign runs a related conversation that has picked up real momentum since spring: what should become of the metadata JSON file itself?

Two threads carry it. One asks the blunt question directly, "metadata.json in v4?", probing whether the top-level file should shrink, change format, or delegate most of its contents elsewhere. The other, "Offloading Snapshots from Metadata.json", attacks the file's biggest source of bloat. Today the metadata file carries the table's snapshot history inline, and for tables with long histories and frequent commits, that log grows until the file is megabytes of JSON that every reader parses and every writer rewrites on every commit. Streaming tables, which commit constantly, feel this worst. The offloading proposal moves snapshot history out of the top-level file into separate structures, so the file every commit rewrites stays small and stable in size.

The thread drew sustained engagement through the spring from a wide slice of the community, Ryan Blue, Yufei Gu, Steven Wu, Jean-Baptiste Onofré, Péter Váry, and others, working through how readers discover offloaded history, how time travel resolves against it, and how the change interacts with the root manifest design. I group these threads with single-file commits as one campaign: every layer of metadata that today gets rewritten wholesale on every commit is being reexamined, and the test each layer must pass is "does the cost of a commit scale with the size of the change, or with the size of the table?" V4's answer, layer by layer, is the change, not the table.

Add the long-standing companion idea of storing manifests in Parquet rather than Avro, so metadata reads get column pruning like data reads, and you can see the full shape: a metadata layer that is columnar, structured, incrementally committed, and slim at the top. Each proposal is votable on its own. Together they are one redesign.

The Hottest Thread of the Season: Efficient Column Updates

If you sort this spring's dev list by message volume, one discussion towers over the rest: efficient column updates in Iceberg. It has drawn more replies than any v4 thread, and the reason is that it sits on a genuinely contested design boundary.

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 and leave the rest alone. Iceberg today offers no way to update a column without rewriting entire rows, which means entire files. Refresh one embedding column and you rewrite two hundred columns of untouched data alongside it. At scale, the write amplification is ruinous, and teams route around Iceberg entirely for these tables.

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 to materialize full rows. Related design work on the thread covers the file representation and the metadata representation for these column-level artifacts, and the current scope focuses on updates that touch a column across all rows, leaving row-subset partial updates for later.

The reason the thread runs to dozens of messages is a real architectural argument, not bikeshedding. One camp asks whether this belongs in Iceberg at all or whether Parquet should solve it, perhaps through logical files that map columns to physical files, especially since Parquet is separately working on cheaper footers. 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 and partial updates, and there is a compelling side observation that independently updatable column families would also cut commit conflicts, since writers updating disjoint families stop contending on the same rows. Gábor Kaszab, Péter Váry, Russell Spitzer, Gang Wu, Anurag Mantripragada, and a rotating cast of others have kept this discussion rigorous for months.

My read as of July: the workload pressure is undeniable and the community clearly intends to serve it, but the layering question, Iceberg versus Parquet versus both, is the least settled major design question in v4. Watch this thread above all others if wide tables are your life.

Deletes Keep Evolving: Compact Bitmaps and the Equality Delete Endgame

V3's deletion vectors were a big win, and I have written a full deep dive on them. The v4 conversation shows the community already sharpening that work along two lines.

The first is the compact bitmap format. 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, with an eye toward the new metadata tree, where compact bitmap-like structures can serve more jobs than row deletion. The thread drew detailed technical review from contributors across several companies, the kind of scrutiny you want on a byte-level format that every engine will implement.

The second is the slow squeeze on equality deletes. Equality deletes, which mark rows dead by value rather than position, remain the write-cheap tool that streaming CDC writers rely on, and they remain expensive for readers until maintenance resolves them. A thread on Flink converting equality deletes to deletion vectors has been working through how the streaming engine that produces most equality deletes in the wild can compact them into position-based vectors closer to write time, shrinking the window where readers pay the equality-matching tax. Combine that with the v4 partition tuple discussion, where one option on the table is redefining equality delete scoping entirely, and the direction is visible: the community is engineering equality deletes into a narrower and more disciplined role, a short-lived buffer rather than a resting state. I would not be surprised if the v4-era guidance eventually treats unresolved equality deletes the way we now treat uncompacted small files, as a condition to monitor and burn down.

The Long Tail: Row Timestamps, Tags, and Capability Signaling

A few smaller threads round out the July picture, and they are worth knowing because small spec changes often deliver outsized quality-of-life gains.

The row timestamp proposal would give rows a spec-level notion of when they were written, building on the row lineage foundation that v3 established. Row lineage gave rows persistent identity across commits, which made change data capture and incremental processing tractable. A trustworthy per-row timestamp extends that story for auditing, temporal queries, and downstream CDC consumers, and the thread has been actively working through semantics with Steven Wu and Micah Kornfield among the participants. Getting time semantics right in a format spec is famously subtle, which is why this one earns its long discussion.

The tags field proposal would add a general-purpose tagging mechanism to v4 metadata structures, giving engines and tools a sanctioned place to attach small annotations without abusing properties maps. And at the REST layer, a discussion about adding a client capabilities header to the catalog protocol addresses a problem v4 itself is creating: as the format grows more optional and more adaptive, catalogs and clients need a clean way to declare what they each understand, so a mixed fleet of engines at different support levels can share tables safely. That last one is the connective tissue that makes a multi-engine v4 rollout survivable, and it is exactly the kind of unglamorous work that determines whether a spec transition goes smoothly.

The Convergence Question, Six Weeks Later

I covered the Databricks convergence announcement at length in June, so here I will just update the temperature.

The pitch, for anyone catching up: Databricks proposed that Delta Lake 5.0 adopt the Iceberg v4 metadata tree as its native content metadata, producing one on-disk structure that both Delta and Iceberg clients read and write directly, with no translation layer. The technical claim is that the two formats already converged on the same ideas, columnar metadata, manifest-style trees, deletion vectors, and maintaining two encodings of the same ideas serves nobody.

What the past six weeks have clarified is the relationship between that narrative and the actual work. The convergence story rides on top of the v4 design process. It does not drive it. The threads I have walked through in this article, partition tuples, root manifest scan costs, snapshot offloading, bitmap formats, are being argued on their engineering merits by contributors from many companies, with Databricks engineers as participants among peers rather than authors of a fait accompli. Whether Delta 5.0 ultimately adopts the resulting tree is a Delta decision. Whether the tree is good is an Iceberg community decision, and it is being made the slow way, in public, one thread at a time. That ordering is healthy, and so far it is holding.

My advice from June stands: treat convergence as a direction to watch, not a plan to build on. The thing to actually build on is the v4 work itself, which will benefit Iceberg users regardless of what Delta does.

Questions I Hear Most Often About v4

Every time I present on v4, at meetups, on the podcast, or in customer conversations, a familiar set of questions comes back. Answering them here fills in the edges, and each answer doubles as a review of the ideas above.

When will v4 ship? Nobody knows, and anyone who gives you a confident date is guessing. What I can offer is the shape of the process. V3 offers the template: the spec was ratified in mid-2025, and engine support then rolled out across the ecosystem over the following year. V4 will follow the same arc, ratification after the open questions resolve, then a staggered implementation wave. The ratified pieces, relative paths and content stats, tell you the process is moving. The open arguments, partition tuples and column update layering, tell you it is not done. My honest read in July 2026 is that the direction is locked and the timeline is not, and that is the correct order for those two things to settle.

Will I have to migrate my tables? Not on anyone's schedule but your own. Format version upgrades in Iceberg are opt-in, table by table, through a property change. Your v2 and v3 tables keep working indefinitely, and every engine that adds v4 support keeps reading older formats. The pattern from past transitions holds: upgrade a table when a specific new capability pays for the change, not because a version number exists. The one planning item worth doing early is an inventory of every engine, tool, and script that touches your tables, since a table upgraded to v4 becomes invisible to a reader that never learned v4. The capabilities-header work on the REST catalog side exists precisely to make that fleet coordination less painful.

Does v4 make v3 adoption a waste? The opposite. Several v4 proposals are direct extensions of v3 features, and running v3 now is how you position 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.

Is v4 mostly about streaming? Streaming is the loudest driver, but I count three, and the balance matters. The commit economics work serves streaming. The stats and metadata-as-data work serves AI and extreme-width tables. Relative paths and the operational threads serve platform teams running Iceberg across regions and disaster recovery boundaries. If your workloads are classic batch analytics on stable tables, v4 will still reach you through faster planning and cheaper maintenance, just less dramatically. The format is widening its coverage, not pivoting.

Should I be worried about the Databricks influence? Attention is warranted. Worry, based on what the list actually shows, is not. The observable facts as of July: proposals get argued by contributors across Google, Apple, Snowflake, Netflix, Microsoft, LinkedIn, Starburst, and many independents, votes happen in public with recorded results, and the two ratified v4 pieces so far went through exactly that gauntlet. The governance test is not whether a large vendor proposes things. Large vendors always propose things, and their production pain makes their proposals valuable. The test is whether a proposal from anyone can pass without community consent, and nothing this year suggests it can. Keep watching, and keep judging by the votes rather than the press cycle.

What happens to my tooling for compaction and maintenance? It evolves rather than disappears, and this is worth internalizing early. The adaptive tree does not eliminate maintenance, it relocates it: rebalancing inlined entries from the root into leaf manifests becomes a maintenance activity in its own right, joining compaction and snapshot expiration on the schedule. Snapshot offloading changes what expiration touches. Column update files, if they land, will bring a stitching cost that maintenance can reduce by materializing updated columns back into base files. The through-line of the whole spec's philosophy holds in v4: writers get speed, readers get stability, and background maintenance is the pressure valve between them. Budget for maintenance being different, not smaller.

How do the Parquet and Arrow projects fit into this? More tightly than most coverage acknowledges. Several v4 questions turn on what the file format beneath the table format can do. The column update debate hinges partly on whether Parquet grows a logical-file concept. Columnar metadata leans on Parquet footer improvements to keep small metadata reads fast. The variant and geo types already live as joint efforts across the Iceberg and Parquet specs, and that co-evolution continues. When I tell people to follow the Iceberg dev list, I increasingly add the Parquet list to the assignment, since the layers are moving together and decisions ricochet between them. My weekly Apache newsletter tracks both for exactly this reason.

What is the single most important thread to watch for the rest of 2026? If I had to pick one, it is the single-file commits sync track, including the partition tuple question, because it is the keystone. The root manifest design determines what snapshot offloading offloads into, what the bitmap structures index, what change detection walks, and what commit costs look like for every workload. Most of the other proposals flex to fit whatever shape it settles into. Second place goes to efficient column updates, because its layering question, Iceberg or Parquet or both, is the most genuinely undecided architecture call on the board, and its resolution will say a lot about how the two projects divide responsibility for the next decade.

Where do I follow all this without making it a part-time job? Three tiers, by effort. Lowest effort: follow recaps from people who read the source, and check the official spec page occasionally for language that says "v4 and later," since spec text is ground truth. Medium effort: skim the dev list archives monthly at lists.apache.org, subjects only, and open anything tagged DISCUSS or VOTE that touches your workload. Highest effort: subscribe to the list and read the design documents linked from the big threads, which is where the diagrams and cost analyses live. The community does all of this in the open specifically so that you can. Take them up on it.

Why This All Coheres

Step back from the individual threads and v4 resolves into one picture with three panels.

The first panel is commit economics. Single-file commits, the root manifest, snapshot offloading, and delta-encoded schemas all attack the same invariant: today, the cost of committing scales with the size of the table's metadata rather than the size of the change. Every one of these proposals rewrites that invariant so streaming-rate commits stop being self-harm.

The second panel is metadata as data. Content stats, aggregate stats, Parquet manifests, and the compact bitmap work all treat metadata as structured, typed, columnar information that deserves the same query optimization machinery as the data itself. Richer metadata that stays cheap to read is what makes planning possible at extreme width and, eventually, what opens the door to the index structures that AI retrieval workloads need.

The third panel is granularity of change. Deletion vectors gave us row-level change without file rewrites in v3. Column update files aim to give us column-level change without row rewrites in v4. Relative paths give us table-level relocation without metadata rewrites. In each case the format learns to express a smaller unit of change, and every smaller unit multiplies what workloads the lakehouse can hold.

Streaming, AI, and operations at scale. Those are the three forces, and every thread on the list maps to one of them. The format is being reshaped by the people who run it hardest, which is the best possible source of design pressure.

What Practitioners Should Do in July 2026

Let me close the technical tour with grounded guidance, updated for exactly where things stand.

Run v3 and actually use it. The 1.11 line is current, and v3 capabilities like deletion vectors, the variant type with shredding, row lineage, and the geo types are where the immediate wins live. 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, not all of them. Streaming teams should follow single-file commits, snapshot offloading, and the Flink equality delete conversion. AI platform teams should follow efficient column updates and the stats work. Multi-region operators should note that relative paths are now ratified and start planning for the day their engines support v4 tables. Reading everything is my job. Reading what matters to your workload is yours.

Learn to read the list yourself. The archives at lists.apache.org are public and searchable, and the JSON API behind them makes it easy to track thread activity programmatically, which is exactly how I keep my newsletters current. An hour a month skimming subjects will keep you ahead of every secondhand summary, including mine.

Discount predictions about timing. Nobody serious has committed a v4 ship date, and the honest tell is the state of the arguments: partition tuples and column update layering are genuinely open. Specs ship after the arguments resolve. What you can bank on is the direction, because the direction is now backed by votes, not just enthusiasm.

And hold the meta-lesson. 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.

Go Deeper

Everything in this article came from following the project at the source: the dev list threads, the design documents, the votes, and the spec text. If you want to build the kind of foundation that makes those sources readable, from metadata internals through operating real lakehouse systems and the AI workloads now reshaping them, that is what my books are for. I co-authored Apache Iceberg: The Definitive Guide and Apache Polaris: The Definitive Guide for O'Reilly, along with further titles on lakehouse architecture, data engineering, and agentic analytics.

Browse the full collection of my books on data and AI at books.alexmerced.com and turn the horizon into working knowledge before it arrives.