Apache Iceberg v4 vs v3 in 2026: Root Manifests, Single-File Commits, and What to Decide Now

A platform team asked me last month which of their tables they should move to Iceberg v4. The question is malformed, and the way it is malformed is the most useful thing in this article. Comparing Apache Iceberg v4 vs v3 is not a comparison between two releases. It is a comparison between one shipped specification and a live negotiation, parts of which have already been settled by recorded public vote and parts of which could still go three different ways. There is no format version 4 you can set on a table today, and nobody has committed to a ship date. But four pieces of v4 are already decided, one of them changes what “upgrade” even means for streaming tables, and the decisions you make in the next two quarters will determine whether that eventual upgrade is a metadata operation or a migration project.

What this covers: the exact ratified-versus-contested split as of September 2026, how the root manifest and single-file commit design actually changes commit mechanics, why the equality-delete vote is the one v4 decision that already constrains your architecture, and a per-table decision procedure that does not depend on a release date.

Context and Background

Apache Iceberg 1.11.0, released in May 2026, is the current stable line and it is firmly a v3-era release. It carries the full v3 feature surface into production-grade status: deletion vectors, the Variant type with shredding, row lineage, native geospatial types, and nanosecond timestamps. The Apache Iceberg releases page still lists 1.11.0 as the latest Java release as of this writing. A 1.12.0 release is in the release-manager pipeline on the dev list — Alex Merced’s weekly dev-list roundup reports release-candidate discussion running through mid-September 2026 — but it had not been announced when this article was written, and it is a 1.x release inside the v3 era regardless.

That distinction matters more than it sounds, because any useful Apache Iceberg v4 vs v3 discussion has to start by separating two version numbers that people routinely confuse. The library version (1.11.0, 1.12.0) tracks the Java implementation. The table format version (v1, v2, v3, v4) tracks the on-disk specification and is a per-table property. A 1.11.0 engine can read v1, v2 and v3 tables. It cannot read a v4 table, because v4 does not exist yet as spec text you can implement against.

What does exist is a spec process running in public. Iceberg design work moves through a recognisable lifecycle: a DISCUSS thread with a design document, then recurring community syncs with written summaries posted back to the list, then a VOTE thread where a committer proposes specific spec text and the community votes over a defined window with recorded results. That machinery is why you can answer “what is actually settled” with evidence rather than vibes, and it is the only honest basis for an Apache Iceberg v4 vs v3 comparison right now.

If you have not yet worked through what v3 gave you, start with our breakdown of the Iceberg v3 spec and upgrade path, because almost every v4 proposal is an extension of a v3 primitive rather than a replacement for it. Deletion vectors are the foundation the compact bitmap work refines. Row lineage is the foundation the row-timestamp proposal builds on. Variant is a major consumer of the new statistics representation. Teams that skip v3 while waiting for v4 get the worst of both timelines.

The Maturity Ladder: What Is Ratified, What Is Engineered, What Is Argued

The correct mental model for Apache Iceberg v4 vs v3 is not a feature table but a maturity ladder with three rungs. Rung one is spec text adopted by recorded public vote. Rung two is heavily developed design with scheduled community syncs and no vote yet. Rung three is a live argument that could resolve several ways. Every v4 headline belongs on exactly one rung, and treating rung-three material as though it were rung-one is how roadmaps go wrong.

Figure 1: The three rungs of Iceberg v4 work as of September 2026 — ratified spec text, proposals in the engineering phase, and questions still genuinely open.

The figure groups the v4 workstreams by how far each has travelled through the Apache decision process. The left branch holds items decided by a recorded vote on the dev mailing list. The middle branch holds proposals with design documents, recurring syncs and named owners, but no vote yet. The right branch holds design questions where competent engineers still disagree about the answer, not merely about the wording.

Rung one: four things are already decided

Relative path support was voted into the v4 spec in mid-May 2026, brought to the vote by Daniel Weeks. Iceberg has always embedded absolute URIs in metadata, with bucket and region baked into every file reference, which meant relocating a table for disaster recovery, region migration or a test clone required rewriting every path in the tree. Under the ratified v4 behaviour, paths are stored relative to a table root supplied by the catalog. Move the directory tree, repoint the catalog, done. Absolute paths remain legal for references that genuinely live outside the table root.

Content Stats was voted into v4 in the same May window, brought by Eduard Tudenhöfner. 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 — with values serialised as binary blobs inside row-oriented Avro manifests. Planning a query on a two-hundred-column table means deserialising statistics for all two hundred columns even when the predicate touches three. Content Stats replaces the maps with a typed, structured representation that is projectable field by field. The type context survives serialisation, which removes a class of subtle hazards as schemas evolve, and the structure can hold things a scalar-per-column map never could: bounds on fields nested inside a Variant, bounding boxes for geometry, and eventually sketches and index structures.

A draft spec for a compact bitmap format was voted into the repository in early June 2026, proposed by Ryan Blue. It refines the bitmap structures underneath v3 deletion vectors, with an eye toward reuse in the new metadata tree.

The fourth item is the one most teams have not internalised, and it is the only one I can point at a primary source for line by line. On 2026-08-18, Huaxin Gao announced on dev@iceberg.apache.org that the vote to forbid new equality deletes in v4 had passed with seven binding +1s and seventeen non-binding +1s, with no 0 or -1 votes. That thread is publicly archived and worth reading in full, because the proposal text is three precise clauses rather than a slogan. I will come back to it, because it is the single v4 decision that already changes what you should be doing this quarter.

The three ratifications above are reported in Alex Merced’s dev-list roundups rather than read by me off the vote threads directly, so treat the attributions and dates as reported; the equality-delete result I quote from the archived thread itself.

Rung two: the root manifest is being engineered, not argued

Single-file commits and the adaptive metadata tree sit in the engineering phase. There is a design document, there are recurring community syncs organised and summarised back to the list by Amogh Jahagirdar, there are appendices mapping options as they get explored, and there are change-detection diagrams contributed by Steven Wu. What there is not, yet, is a vote.

Alongside it run two smaller proposals aimed at the same invariant. Snapshot offloading moves the table’s snapshot history out of the top-level metadata JSON, so the file every commit rewrites stops growing with table age. Delta-encoded schemas store schema changes as diffs rather than appending a complete schema copy on every evolution, which matters for wide tables with long histories that currently drag hundreds of full schema copies through every metadata read.

Read those three together and the campaign is obvious. Every layer of metadata that is currently rewritten wholesale on every commit is being re-examined against one test: does the cost of a commit scale with the size of the change, or with the size of the table? That test, not any single feature, is what v4 is for.

Rung three: three questions are genuinely open

The partition tuple is the loudest. Today 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 one root can reference files spanning multiple specs. Ryan Blue opened a dedicated thread exploring an option that eliminates the stored tuple entirely and reconstructs 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.

Efficient column updates is the highest-volume thread of the year, and the argument is architectural rather than cosmetic: should Iceberg grow column update files that are stitched to base files at read time, or should Parquet grow a logical-file concept and solve it one layer down? Contributors including Gábor Kaszab, Péter Váry, Russell Spitzer, Gang Wu and Anurag Mantripragada have kept that question open for months.

Third, Steven Wu has proposed that v4 manifests be Parquet-only, dropping Avro from the metadata layer entirely so that projecting column statistics from manifests gets the same column-pruning treatment as data reads. That is reported from the dev-list roundups and is in-flight, not settled. Do not build a plan on it.

Inside the Metadata Tree: What Root Manifests Actually Change

The cleanest way to understand Apache Iceberg v4 vs v3 at the mechanism level is to trace one tiny commit through both trees and count what gets written.

An Iceberg table today is a tree of files. Data files hold rows. Manifest files list groups of data files with per-file statistics. A manifest list, one per snapshot, collects the manifests that make up one consistent version of the table. A metadata JSON file at the top records schema, partition specs, sort orders, snapshot history and a pointer to the current snapshot. The catalog holds the pointer to the current metadata file, and a commit is an atomic swap of that pointer.

Figure 2: The v3 commit cascade. Adding a single small data file still writes a new metadata JSON, a new manifest list and at least one new manifest before the catalog pointer can be swapped.

The diagram traces one small append through the current format. The writer produces the data file, then a manifest describing it, then a manifest list that references that manifest plus every prior manifest still live in the snapshot, then a metadata JSON carrying the schema and the growing snapshot log. Only after all four exist can the catalog swap the pointer, which is why commit cost in v3 is a function of table metadata size rather than change size.

The cost model that broke

That design assumes commits are relatively infrequent, tables are modest in width, and tables rarely move. All three assumptions held in 2018 and none of them holds for the workloads driving v4.

Streaming broke the first. A job committing every few seconds pays the full cascade every time, so metadata writing dominates the actual work, small metadata files pile up against storage prefixes until the object store starts throttling, and the compaction jobs meant to clean up end up competing with the ingestion they exist to support. AI feature tables broke the second: hundreds of columns of statistics deserialised on every plan. Multi-region operations broke the third, which is what relative paths address.

What the root manifest does instead

The proposal restructures the tree around a Root Manifest that replaces the manifest list and becomes the single entry point for a snapshot. The hierarchy flattens. Critically, the root gains the ability to inline small changes directly into itself, so a tiny commit writes one file rather than a cascade. As inlined entries accumulate, background maintenance rebalances them down into leaf manifests, restoring the layered structure that keeps planning fast on very large tables.

Figure 3: The proposed v4 adaptive tree. A small commit writes only the root manifest with its change inlined; background maintenance later rebalances inlined entries into leaf manifests.

The figure shows why the design is called adaptive. A hot streaming table keeps recent writes inlined near the root, so commits stay cheap. A batch table settles into the classic layered shape, so planning stays cheap. Readers must consult both the inlined entries and the leaf manifests during scan planning, which is precisely where the design tension lives — and the arrow from maintenance back into the leaves is the pressure valve that keeps the two regimes from colliding.

I want to be blunt about the numbers here, because the vendor coverage is not. No benchmark has been published for commit latency, write amplification or metadata file counts under the root manifest design, because the design is not implemented in a released format. Anybody quoting you a multiple is extrapolating. What you can reason about confidently is the shape of the change: commit cost stops scaling with metadata size and starts scaling with change size, and planning cost acquires a new term proportional to the number of inlined entries not yet rebalanced.

The read-side argument nobody should skip

That new planning term is the substance of the open debate. Inlined entries are excellent for writers and a fresh burden for readers, who must scan them during planning. List participants have pushed hard on the consequences, and the question has a sharp catalog dimension: a REST catalog doing remote scan planning may have to partially decode a large number of inlined entries per planning request under high concurrency. Push too much of that work into the catalog and you have quietly turned it into a small query engine with its own scaling story. Flush entries down to leaves too eagerly and you resurrect the small-file storm the design exists to end.

If your catalog is a shared service, that trade is your problem as much as the format’s. Our comparison of Polaris, Nessie and Unity as Iceberg catalogs is the right companion read, because the catalog you picked in 2025 acquires new responsibilities under this design.

Why the partition tuple question is not a detail

The partition tuple thread looks like housekeeping and is not. Removing the stored tuple and reconstructing partition information from column bounds works cleanly when bounds are exact. String and binary columns, however, can carry truncated bounds in statistics, which breaks the reconstruction for identity-partitioned string columns unless writers are required to keep exact bounds for those fields. That is a real constraint on writers, not a footnote.

The second complication is that the main consumer of partition tuples turns out to be equality delete matching, which raises a further option discussed on the thread: make v4 equality deletes global and scope their application by statistics rather than by partition. Every branch of this decision costs something. Keeping the tuple keeps the coupling the new tree wants to break. Reconstructing from bounds demands exactness guarantees from every writer implementation. Going global changes delete semantics. This is why the thread runs long, and why treating any of the three as settled would be wrong.

The Delete Path: The One v4 Decision That Already Binds You

Everything above is a horizon. The equality-delete vote is not, and this is where an Apache Iceberg v4 vs v3 comparison stops being a reading exercise and starts being a work item.

The proposal that passed on 2026-08-18 has three clauses. First, writing new equality deletes is forbidden for v4 tables, because the v4 metadata will not define equality deletes as an allowed entry type. Second, reading equality deletes remains supported in the reference implementation for backward compatibility, both for existing v2 and v3 tables and for equality deletes carried over into upgraded v4 tables. Third, upgrading a v2 or v3 table to v4 is metadata-only, with no synchronous rewrite of data or delete files; existing equality deletes remain in carried-over v2 and v3 delete manifests, and converting them to deletion vectors is a separate, optional maintenance action.

The vote result is recorded. The spec text was a separate follow-up — Huaxin Gao stated on 2026-08-20 that a PR for the spec change would follow — so the correct characterisation today is decided by vote, spec language landing separately. Do not quote it as final spec prose.

Why this was voted through, and why it took two years

The rationale in the vote email is compact and worth understanding as an engineering argument rather than a policy one. Equality deletes impose an asymmetric cost paid on every read, complicate the format, and block features including change data capture, row lineage, and incremental index or materialized-view maintenance.

Take those in order. An equality delete file says “rows with these values are deleted” without saying which data files those rows live in, so a reader cannot skip the check; it has to join candidate data files against applicable delete files on the equality columns. Sequence numbers and partition scoping narrow the candidate set, and column metrics prune some of it, but real change-data-capture streams scatter updates across the key space so value ranges overlap nearly every data file in the partition. A deletion vector, by contrast, is a bitmap of deleted row positions for exactly one data file; the reader does an array lookup. That is a difference in algorithmic shape, not a tuning difference.

The correctness consequences are worse than the latency ones. Producing a changelog between two snapshots requires knowing which rows a delete removed, and with equality deletes that fact is not knowable from metadata alone — it requires scanning data. Row lineage, added in v3, assumes the system knows which physical row an update replaced; equality deletes hide that by construction. Any materialized view or secondary index that stays current by applying snapshot deltas falls back to a full rebuild.

Russell Spitzer first proposed deprecating equality deletes back in October 2024 and the proposal stalled, for a concrete reason: Flink streaming upserts depended on them and had no practical replacement. The blocker cleared in 2026. Per Alex Merced’s reporting of the dev list, Maximilian Michels confirmed that equality-delete-to-deletion-vector conversion is complete and merged as a Flink table maintenance task named ConvertEqualityDeletes, integrated with IcebergSink. The design keeps the cheap write path and moves the expensive key-to-position lookup into an asynchronous task backed by a sharded primary-key index in Flink state. That is what made the ban votable.

What the third clause really buys you

Clause three is the one to read twice. Making the v4 upgrade metadata-only decouples v4 adoption from delete-file migration. You can move a table to v4 on your own timeline and burn down its equality deletes as background maintenance afterwards. Without that clause, upgrading a large streaming table would have been a multi-week operational project rather than a property change. One non-binding voter on the thread called this out explicitly as the underrated part of the proposal, and I agree.

The practical consequence: the work that pays off regardless of when v4 ships is getting off equality deletes. That work is available today on v3, needs no v4 spec, and has an unambiguous success metric — zero equality delete files on the branch your readers query.

Where the gap still hurts

Honesty requires naming who this hurts. Iceberg Kafka Connect writes equality deletes for upserts and has no equivalent maintenance task. A Connect-based ingestion pipeline needs either a separate Flink or Spark maintenance job alongside it, or a rewrite of the ingestion path. That gap is one of the genuinely open items in the discussion, and it is a fair argument that the timeline should be generous.

Decision Matrix: What Each Workload Should Do Now

The thesis of this article is that v4 is not one release but three simultaneous renegotiations — commit economics, metadata as data, and granularity of change — and each maps to a different workload. That is why the correct action is per-table, not per-organisation.

Workload	Dominant v4 thread	v3 action available today	What v4 will change	Decision now
Flink or Connect CDC upserts	Equality delete ban; single-file commits	Upgrade to v3, stand up ConvertEqualityDeletes, monitor equality-delete count	New equality deletes forbidden; commits stop scaling with metadata size	Act now — this is ratified and the conversion path exists
High-frequency streaming appends	Root manifest, snapshot offloading	Tune commit interval and compaction; expire snapshots aggressively	Small commits write one file; snapshot log leaves metadata JSON	Track the syncs; do not restructure pipelines on a design doc
Wide feature or embedding tables	Efficient column updates; Content Stats	Reduce table width where possible; use Variant for sparse attributes	Column-level updates without row rewrites; projectable statistics	Watch the Iceberg-versus-Parquet layering argument before designing around it
Multi-region or DR-critical tables	Relative paths	Script the path-rewrite migration you currently need	Table relocation becomes a catalog pointer update	Ratified — plan for it, but you still need engine support
Classic batch analytics	None dominant	Adopt v3 deletion vectors and geospatial or Variant types as needed	Faster planning, cheaper maintenance, less dramatically	No v4 action required

Two cells deserve emphasis. The DR row is ratified but not usable, because ratified spec text without engine implementations buys you nothing operationally. The CDC row is the only one where the correct action is “start this quarter” — and the action lives entirely in v3.

If you are still choosing a format rather than operating one, the trade-offs sit in a different place entirely, and our Iceberg versus Delta versus Hudi architecture decision record and the Iceberg versus Paimon comparison cover the primary-key-upsert question that this article assumes you have already answered.

Trade-offs, Gotchas, and What Goes Wrong

The dominant failure mode in format-version planning is not picking the wrong version. Framed as Apache Iceberg v4 vs v3, the risk looks like a choice; in practice it is an operational hazard, and it is upgrading a table that something still reads.

A table upgraded to a format version becomes invisible to any reader that never learned that version. Not slow — invisible, or worse, wrong. Iceberg format upgrades are one-way in practice and metadata-only in cost, which makes them feel trivial and makes the blast radius easy to underestimate. The set of things that read your tables is almost always larger than the set you can name from memory: the query engines, yes, but also the BI tool’s own connector, the Python jobs using PyIceberg, the Go or Rust service somebody wrote to tail a table, the catalog’s own metadata endpoints, and whatever internal exporter feeds the data catalog.

Figure 4: The per-table decision procedure. Reader inventory comes first, v3 adoption second, equality-delete retirement third, and only then does workload classification decide which v4 thread you need to track.

The figure puts the reader inventory before every other step deliberately. Upgrading first and auditing afterwards is the sequence that produces silent correctness incidents, because a reader that partially understands a newer format returns rows rather than errors.

This fleet-coordination problem is understood inside the project, which is why a REST catalog client-capabilities header is under discussion — a sanctioned way for clients and catalogs to declare what each understands, so a mixed fleet at different support levels can share tables safely. It is unglamorous work that will determine whether the v4 transition is smooth.

Two more specific traps. First, conformance drift between implementations is real, and the project has started treating it as a first-class problem: apache/iceberg-verification exists to provide language-neutral conformance fixtures whose expected values are derived from the spec rather than copied from any implementation. Its README states the motivation plainly — the specification is prose, each implementation parses and serialises it independently, so they drift, and tests maintained in isolation cannot catch a shared misreading. Read the scope note too: initial scope is read conformance, adoption is by self-election, and there is explicitly no central conformance gate and no pass/fail matrix. It is a tool for you to use, not a certification you can rely on a vendor having passed.

Second, do not treat the Databricks convergence story as a plan. Databricks proposed that Delta Lake 5.0 adopt the Iceberg v4 metadata tree natively. That is a proposal and a direction. Delta 5.0 has not adopted it, and whether it does is a Delta decision that rides on top of the v4 design process rather than driving it. Architecting on the assumption of a single shared on-disk tree would be building on an announcement.

Third, and most quietly expensive: maintenance does not shrink under v4, it relocates. Rebalancing inlined entries from the root into leaf manifests becomes a scheduled maintenance activity in its own right, joining compaction and snapshot expiration. Snapshot offloading changes what expiration touches. Column update files, if they land, bring a stitching cost that maintenance reduces by materialising updated columns back into base files. Budget for maintenance being different, not smaller.

Practical Recommendations

The action list that survives every plausible v4 timeline is short, and none of it requires v4. Strip the Apache Iceberg v4 vs v3 framing away and what remains is ordinary lakehouse hygiene that happens to position you well.

Run v3 and actually use its features. The 1.11.0 line is current and deletion vectors, Variant with shredding, row lineage and the geospatial types are where the immediate wins are. Teams debating v4 timelines while running v2 tables with unconverted equality deletes have their priorities inverted.

Treat the reader inventory as the deliverable, not the upgrade. Enumerate every process that opens your tables, record the Iceberg library version and format-version support for each, and keep that inventory current. It is the artifact that makes every future format decision cheap.

Measure before you migrate. Run a representative query against a snapshot with delete files present and against one immediately after compaction. If the gap is small, delete accumulation is not your bottleneck and conversion work is misdirected effort.

Track only the threads that map to your pain. Streaming teams follow single-file commits, snapshot offloading and the Flink conversion work. AI platform teams follow efficient column updates and the statistics work. Multi-region operators note that relative paths are ratified and watch for engine support.

A checklist you can run this quarter:

• [ ] Inventory every reader and writer, with library version and format-version support recorded per entry.
• [ ] Move remaining v2 tables to v3 — but only after the inventory confirms deletion-vector read support everywhere.
• [ ] Query the delete_files metadata table weekly, grouped by partition, and alert on an equality-delete count that climbs without falling back.
• [ ] Stand up equality-delete conversion on your single most painful table using a staging-branch topology, and watch it for a month before generalising.
• [ ] Pin and run apache/iceberg-verification fixtures against any non-reference implementation you depend on.
• [ ] Add “rebalance or compact metadata” as a placeholder line item in your maintenance budget for the v4 era.
• [ ] Discount every v4 timeline you are given, including vendor roadmaps, until the partition-tuple and column-update threads resolve.

Frequently Asked Questions

When will Apache Iceberg v4 ship?

No date has been committed, and anybody quoting one is guessing. The honest tell is the state of the arguments: the partition-tuple question and the Iceberg-versus-Parquet layering of column updates are both genuinely open, and specs ship after arguments resolve. What you can rely on is direction, because four pieces are backed by recorded votes rather than enthusiasm. The v3 precedent suggests ratification first, then a staggered wave of engine implementations over the following year.

Is Apache Iceberg v4 vs v3 a decision I need to make now?

Not as stated. There is no v4 to choose. The decision you actually face is which v3 capabilities to adopt and whether to retire equality deletes, and both are available today. The one v4 ratification that constrains present-day architecture is the equality-delete ban, and the correct response to it — converting equality deletes to deletion vectors — is a v3 activity that pays off immediately in read latency regardless of when v4 arrives.

Will I have to migrate my tables to v4?

Not on anyone’s schedule but your own. Format-version upgrades in Iceberg are opt-in per table through a property change, your v2 and v3 tables keep working indefinitely, and engines that add v4 support keep reading older formats. The vote explicitly made v4 upgrade metadata-only, with no synchronous rewrite of data or delete files. The planning item to do early is the reader inventory, because a table upgraded to a format version becomes invisible to readers that never learned it.

Does adopting v3 now become wasted work when v4 lands?

The opposite. Several v4 proposals are direct extensions of v3 primitives. The compact bitmap work refines deletion vectors. The row-timestamp proposal builds on row lineage. Content Stats is consumed heavily by the Variant type. Running v3 today is how you build the operational familiarity v4 assumes as a starting point, and the conversion infrastructure you stand up for equality deletes is exactly what the v4 ban requires you to have.

What actually changes for readers under the root manifest design?

Readers gain a new planning cost proportional to the number of entries inlined near the root and not yet rebalanced into leaf manifests. On a hot streaming table that count is nonzero by design. That is the live trade being priced on the dev list: write throughput against planning cost, with background maintenance as the tuning knob between them. Nobody has published measurements, because the design is not implemented in a released format version.

Is the equality-delete ban final spec text?

The vote passed on 2026-08-18 with seven binding and seventeen non-binding +1s and no dissent, which is a recorded community decision. The spec-text pull request was a separate follow-up announced two days later, so the accurate phrasing is decided by vote, with spec language landing separately. Reading equality deletes stays supported for backward compatibility; only writing new ones becomes forbidden on v4 tables.

Further Reading

• Apache Iceberg v3 spec features and the upgrade path — what deletion vectors, Variant and row lineage actually give you, and how to upgrade a v2 table safely.
• Iceberg vs Delta vs Hudi: a lakehouse architecture decision record — the format-selection analysis this article assumes you have already done.
• Apache Iceberg vs Paimon for lakehouse table formats — the LSM alternative for primary-key upsert workloads, which is the shape equality deletes were papering over.
• Iceberg catalogs compared: Polaris vs Nessie vs Unity — relevant because remote scan planning and the client-capabilities work push more responsibility into the catalog.
• Apache Iceberg releases — the authoritative record of which library version is current.
• The archived v4 equality-delete vote thread on dev@iceberg.apache.org — the primary source for the proposal text, the rationale and the recorded result.
• apache/iceberg-verification — language-neutral conformance fixtures for testing your own implementations against the spec.

By Riju — about