+1 (non-binding ) The asymmetric cost argument is the decisive factor for me.
An equality delete allows the writer to offload work onto every subsequent read, and this deferred cost is neither bounded nor visible to the party that generated it. Deletion vectors make that cost explicit and ensure it is paid only once. I would also like to highlight point 3, which I think is underrated: making the upgrade metadata-only decouples V4 adoption from delete file migration. Users can move to V4 on their own timeline and convert equality deletes as a background maintenance task. Coupling the two would have turned V4 adoption into a weeks-long operational project for large tables. Cheers, Gianluca Il giorno gio 13 ago 2026 alle ore 19:57 Neelesh Salian < [email protected]> ha scritto: > +1 (non binding) Thank you Huaxin. > > On Wed, Aug 12, 2026 at 19:07 huaxin gao <[email protected]> wrote: > >> Hi all, >> >> Following the discussion thread "[DISCUSS] Deprecate Equality Deletes in >> Iceberg V4" [1], I'd like to call a vote on the following proposal for the >> V4 table spec. >> >> Proposal >> -------- >> 1. Writing new equality deletes is forbidden for V4 tables: the V4 >> metadata >> will not define equality deletes as an allowed entry type. >> >> 2. Reading equality deletes remains supported in the reference >> implementation for backward compatibility, both for existing V2/V3 >> tables and for equality deletes carried over into upgraded V4 tables. >> >> 3. Upgrading a V2/V3 table to V4 is metadata-only (no synchronous rewrite >> of data or delete files). Existing equality deletes remain in carried- >> over V2/V3 delete manifests; converting them to deletion vectors is a >> separate, optional maintenance action. >> >> Rationale >> --------- >> Equality deletes impose an asymmetric cost paid on every read, complicate >> the format, and block features such as CDC, row lineage, and incremental >> index/materialized-view maintenance. Deletion vectors make deletion a >> flat, >> one-time cost, and the Flink ConvertEqualityDeletes work demonstrates a >> viable replacement path, so we do not need the full replacement completed >> before forbidding new equality deletes in V4. >> >> The vote will be open for at least 72 hours. >> >> [ ] +1 Forbid writing equality deletes in V4 >> [ ] +0 >> [ ] -1 Do not forbid (please explain) >> >> [1] https://lists.apache.org/thread/ks01jpv40qjlvz4yop5tlqv4x5oxbwy6 >> >> Thanks, >> Huaxin >> >
