Skip to content

[EPIC] Production-quality native Iceberg writes #5649

Open

Description

@andygrove

What is the problem the feature request solves?

Native Iceberg writes landed in three parts under #4322: the split writer/committer plan (#4658), the eligibility allowlist with fall-back reasons (#5298), and the iceberg-rust data-file writer with JVM-side manifest metrics (#5361). #4322 closed when #5361 merged, and no issue tracks what remains between "merged behind two off-by-default flags" and "production quality". The open follow-ups exist but are not linked to each other, and several gaps had no issue at all.

This epic is that plan. The goal is unchanged from #4322: an ETL job that scans, transforms, and writes Iceberg tables runs natively end to end, and falls back to iceberg-java wherever the native path cannot reproduce its outcome.

Current state (2026-10-13). Comet's Iceberg write path is on by default in 1.2.0, on every Spark version (#6664). spark.comet.write.iceberg.enabled (renamed from spark.comet.iceberg.write.enabled by #5306) defaults to true and plans both the split operator and the native writer, and spark.comet.write.iceberg.splitOperator.enabled is a testing setting. #5644 lists the evidence to gather before 1.2.0 ships. Each Iceberg Spark test job's summary reports which writer ran each write (#6155). In the merge-queue run that merged #6664, 7,175 of the 13,677 writes in the Iceberg 1.11 jobs ran natively (52.5%), up from 47.5% on 2026-10-06, mostly because format-version 3 tables are now admitted (#6668). Most of the rest are Avro and ORC tables (2,458), merge-on-read WriteDelta (1,477), input that is not in Arrow format (1,058), format-version 4 (581), and format-version 3 copy-on-write and compaction writes, which carry row lineage (215). Phase 1 is done, and Phase 2 has one open issue, with a PR.

Describe the potential solution

Phased, in priority order. Each item is a linked issue; check it here when it closes.

Phase 1: correctness blockers

Phase 2: failure handling parity with iceberg-java

Phase 3: coverage so common workloads stay native

Phase 4: enable by default

Phase 5: performance

#6911 tracks the rest of what profiling the end-to-end benchmark (#6910) found, including the parquet-rs encoding work upstream.

Ongoing

Additional context

Done and merged: #4658 (split-operator plan), #5298 (eligibility detection), #5361 (native writer). Related umbrellas: #5121 (DataSource V2 writes in general), #1625 (native Parquet writes for the V1 path).

Native write bugs filed and fixed since this epic was opened, outside the phases above: #5689, #5690, #5691, #5693, #5694, #5698, #5776, #5836, #5837, #6771. #6659 (float value and null counts under a NULL struct on Iceberg 1.9+) was closed as a divergence the user guide already lists; #6681 corrected the Iceberg version the guide gives for it. Open outside the phases: #6803, where five CometIcebergWriteDetectionSuite tests assume a split write plan and fail once #6780 makes a write over a local table scan fully native.

The accepted divergences between iceberg-rust and iceberg-java output are documented in iceberg-writes.md; changes to that list belong in the issues above rather than here.

Activity

  1. andygrove commented on Sep 2, 2026

    @andygrove
    MemberAuthor

    cc @jordepic @comphead @hsiang-c @mbutrovich. Let me know if I missed anything.

  2. jordepic commented on Sep 4, 2026

    @jordepic
    Contributor

    For #5647 I think both my original change and yours have some attached benchmarks. 5648 seems like an important one. I know @unikdahal also will eventually want merge into operations accelerated.

    Ah, another one I didn't cover - writes to MOR (merge on read) tables (positional deletes/deletion vectors). Iceberg rust didn't support these a while ago and it still doesn't. We could recreate them ourselves, but it seems dumb to jump the gun - I just have had a really hard time upstreaming to iceberg-rust so it doesn't leave me with a ton of confidence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions