It would be great to make V4 manifest Parquet-only. This simplifies the spec and the implementation complexity and should improve read performance as Steven noted. Also we don't currently keep track of the root manifest format currently. So if we really want to support Avro root manifests, we need to start tracking the format. The alternative is to require writers to always produce the root manifest in Parquet. But then there is no point in supporting Avro leaf manifests if writers are required to produce root in Parquet anyway.
Note that for v4 table upgrades we will support v3 leaf manifests which are in Avro - so the Parquet restriction applies to new V4 manifests only. Best, Anoop On Tue, Aug 11, 2026 at 11:29 AM Steven Wu <[email protected]> wrote: > Hi, > > During today’s column update sync, we discussed whether to keep the Avro > format option for V4 manifest files. The initial inclination was to keep it > because it already exists, even though Avro won’t support projection reads > on manifest files (including column stats). > > With both Avro and Parquet available, integrations and engines would need > to choose. We expect most will pick Parquet for projection-read support. > That raises a question: should we instead require Parquet for V4 manifests > to reduce the cognitive and decision burden on integrations? > > This also aligns with Iceberg’s usual priority of read > performance—especially query scan planning, where projecting column stats > from manifests matters. > > In the sync, most people generally agreed with making V4 manifests > *Parquet-only*. I’m sending this to collect any feedback or concerns from > the broader community before we settle on that direction. > Thanks, > Steven > > P.S. I uploaded the recording to the YouTube channel here > <https://youtu.be/dDZKzz3PKIk?t=2925> (relevant discussion started at > 48:45). >
