Apache Iceberg 1.12 and Iceberg Rust 0.11 are close to the finish line, and neither one is a routine patch. Apache Iceberg 1.12.0 for Java carries 210 merged pull requests on its milestone. Iceberg Rust 0.11.0 packs roughly two months of work, including end-to-end table encryption and Variant support. Both went through release candidate trouble in mid-September 2026, which tells you something about how much changed.
As of September 18, 2026, neither release is final. The Iceberg 1.12.0 release manager, Neelesh Salian, told the dev list the release candidate is ready to cut. The Rust 0.11.0 vote failed twice and waits on one more fix before RC3.
That gives you a short window to prepare. This preview walks through what's new in Iceberg 1.12.0 and Rust 0.11.0, which changes will break existing jobs, and what to test before you upgrade. The feature list below comes from the merged pull requests on each release's tracking milestone and changelog, so treat it as the expected contents, not the final release notes.
TL;DR: Iceberg 1.12 removes Spark 3.4 support and position deletes with row data, while expanding geospatial, Variant, encryption, Flink, and V4 groundwork. Iceberg Rust 0.11 adds end-to-end encryption and stronger V3 reads, but introduces REST authentication and scan API changes. Test both releases across every engine that reads or writes the same tables.
Iceberg 1.11.0 took roughly eight months to ship after 1.10.0. When Neelesh opened release planning in June, he set a target of about three months, and the community mostly hit it. The cadence change matters on its own. If a feature misses 1.12.0, it waits about three months for 1.13.0, not most of a year.
The bigger story is what's inside. Iceberg 1.12.0 is the release where the V3 features that looked finished on paper get the engine plumbing they need, and where V4 groundwork starts landing in core.
The V3 spec added geometry and geography types. Iceberg 1.12.0 wires them through the stack. The milestone includes PRs that map both types to Parquet logical types, read and write WKB values in Parquet, read and write them in Avro, and track avg_value_size_in_bytes for geo columns. Spark 4.1 gains type mapping plus read and write support for geometry and geography in Parquet, with a fallback from vectorized reads.
If your team stores location data as strings or longitude and latitude doubles today, 1.12.0 is the first Java release where native geo columns are worth a serious test.
Variant, the semi-structured type from V3, got a long list of fixes and extensions. Spark adds vectorized Parquet reads for Variant columns. Flink adds support for writing shredded Variant. Kafka Connect and generic Record writers can now shred Variant into Parquet columns, which is the change that makes Variant practical for streaming ingestion.
The less glamorous fixes matter just as much. The milestone fixes shredding for decimals with precision above 18, corrects Variant string bounds to use UTF-8 byte order, and fixes a crash when a Variant value column has no statistics. Those are the bugs that silently skew pruning, and it's good to see them closed before Variant goes mainstream.
Don't expect Spark to create V3 tables by default yet. Cheng Pan asked about that in August, and Neelesh replied that gaps in Variant and geo support need to close first, so it won't happen in 1.12.
This is the section to share with whoever owns your Spark and Flink jobs. Several removals land in 1.12.0, and they break code, not just deprecate it.
rewrite_position_delete_files and rewrite_table_path actions now fail with an explicit exception on files that still carry row data, a choice the community agreed on at its August 26 sync.SparkTableUtil methods in Spark 4.0 and 4.1, and SparkFilters is now deprecated in favor of SparkV2Filters.RemoteSigningConfig implementation (PR #17709) follows the formalized remote signing spec.The PDWR change deserves a closer look. If you still run V2 tables with position deletes that include row data, your maintenance jobs will start failing after the upgrade. You have two ways out, according to Hongyue Zhang's proposal: upgrade the table to V3 and rewrite the deletes as deletion vectors, or stay on V2 and let data compaction fold those deletes into data files. Pick one before you upgrade, not after the first failed job.
Spark 4.2 is a deliberate omission. Anton Okolnychyi argued that each new Spark release is a chance to fix DSv2 tech debt, so the community merged the Spark 4.2 module into main but excluded it from the 1.12.0 source and binary artifacts. Flink moves the other way: PR #17849 adds Flink 2.2 and 2.3 while keeping 2.1.
Beyond types and removals, 1.12.0 adds features you'll notice in day-to-day operations.
Flink gets a full equality delete conversion pipeline. A series of PRs adds the planner, operators, DV resolution, committer, and integration with IcebergSink. Equality deletes are cheap to write and expensive to read, so converting them into deletion vectors in the streaming job itself is a big deal for CDC pipelines that feed analytics.
Spark's rewrite_data_files gains a Hilbert-curve clustering strategy (PR #16827). Z-order already existed, and 1.12.0 also fixes a Z-order crash on null booleans. Hilbert curves keep nearby values closer together than Z-order in many layouts, so test both on your widest filter columns.
The REST catalog side picks up useful fixes and additions. Path segments now use RFC 3986 percent-encoding (PR #15989), which fixes names with special characters. The OpenAPI spec adds an unregister table endpoint, list and load function endpoints, and a Variant type. Spark adds a property to delegate DROP TABLE PURGE to REST catalogs, so the catalog, not the client, decides how to delete files. That's the right place for that decision.
Encryption keeps maturing too. The last blocker for the release, PR #17984, commits manifest list encryption keys together with the snapshot that uses them. Spark's rewrite_manifests now encrypts the manifests it writes.
Iceberg 1.12.0 doesn't ship V4 tables. It does ship a lot of V4 plumbing. The spec gains content stats and relative paths. Core adds TrackedFile builders and adapters, location relativization utilities, optional metadata locations, and the ability to write Parquet or Avro manifests for V4. The spec also gains an expression specification for storing and exchanging expressions.
You won't use any of this directly yet. But relative paths are the piece that makes moving a table between buckets or regions a metadata operation instead of a rewrite, and that's worth watching.
Iceberg Rust 0.11.0 is the release that makes the Rust library a real peer for encrypted and V3 tables. The 0.11.0 changelog lists more than 80 changes since 0.10.1.
Encryption dominates the list. The work reads and writes encrypted Parquet data files, manifest files, manifest lists, and Puffin files, supports AES-256 keys, and adds a KMS factory trait wired into catalogs. That's the full path from key management to data at rest.
V3 read support grows up. Rust 0.11.0 decodes deletion-vector Puffin blobs and applies V3 deletion vectors during scans. It adds Variant support and materializes row lineage metadata columns, including _row_id and _last_updated_sequence_number. The _pos, _spec_id, and _partition metadata columns arrive too, along with a history metadata table.
Catalog work stands out as well. A new AuthManager and AuthSession API replaces the old OAuth2 handling for REST, and a new SessionCatalog trait comes with a REST implementation. The REST client parses server-advertised endpoints from GET /v1/config and respects them. FileIO is now serializable, which matters for distributed engines that ship work to other processes.
The changelog flags several API changes. The OAuth2 migration to AuthManager changes REST auth setup. Table properties now parse lazily through getters. FileScanTask construction now validates its inputs. The writer honors write.metadata.path, and the GCS host property changed. On the dependency side, the DataFusion integration accepts the whole DataFusion 54 line.
If you pin crates, a Cargo.toml update looks like this:
[dependencies]
iceberg = "0.11"
iceberg-catalog-rest = "0.11"
iceberg-datafusion = "0.11"
Plan for the iceberg-datafusion line to change after 0.11. In September, both the Iceberg and DataFusion communities voted unanimously to move that integration into a new apache/datafusion-iceberg repository under the DataFusion project. Future versions of the integration will follow DataFusion's release process.
The Rust release stumbled twice, and both failures teach something. RC1 failed because a circular dev-dependency between iceberg and the new iceberg-property-macro crate made cargo publish impossible. Kevin Liu fixed the cycle and added a publish dry run to CI.
RC2 failed for a more interesting reason. Alexander Bailey found that the Rust encryption work skipped the tamper-proofing checks Java requires, so files written by the Rust candidate were unreadable in Java. The fix, iceberg-rust PR #3236, is the gate for RC3.
That's the strongest argument for the community's new apache/iceberg-verification repository, which will hold shared conformance fixtures for every implementation. A Rust writer can pass every Rust test and still produce files a Java reader rejects. Cross-engine tests catch that. Unit tests don't.
Multi-engine tables are the whole point of Apache Iceberg, and these two releases show why engine interoperability needs testing. Your Spark jobs, Flink pipelines, Rust services, and query engines all read the same metadata. Any one of them can fall out of step.
Dremio, a key Iceberg contributor and co-creator of Apache Arrow and Apache Polaris, runs as a native Iceberg lakehouse, so your tables stay in your object storage in the open format. Dremio's Open Catalog, powered by Apache Polaris, speaks the Iceberg REST protocol. That means the REST catalog fixes in 1.12.0, like correct path encoding and catalog-side purge delegation, apply to the same catalog your other engines use.
During an upgrade, a single place to validate results pays off. In Dremio's published 1 TB TPC-DS benchmark, its Iceberg-native engine ran the workload 20x faster than Snowflake. Dremio can also join Iceberg tables with sources you have not migrated through Zero-ETL Federation, so you can compare a table written by an upgraded Spark job against the source system without copying either.
Reflections help after the upgrade too. As you adopt Variant or geo columns, Autonomous Reflections can accelerate repeated dashboard and agent workloads without asking analysts to rewrite queries. The AI Semantic Layer also gives agents connected through Dremio's MCP Server the business context for those new columns.
Don't wait for the release announcement to start planning. Three tasks are worth doing this week. First, search your maintenance jobs for V2 tables with position deletes that include row data, and decide whether each one moves to V3 or relies on compaction. Second, inventory any Spark 3.4 workloads and any code calling deprecated SparkTableUtil or S3 signer classes. Third, if you run Iceberg Rust, stage a test that writes an encrypted table with the 0.11.0 candidate and reads it back with Java.
Expect V3 adoption to accelerate once 1.12.0 ships. Geo types, shredded Variant from streaming writers, and deletion vectors in Flink cover the three workloads that kept most teams on V2. The Rust release, once RC3 passes, closes the last big gap for non-JVM engines. Before upgrading a production table, review what changes between Apache Iceberg V2 and V3 and verify every engine in the path supports the features you plan to use.
No. As of September 18, 2026, Apache Iceberg 1.12.0 is still preparing its release candidate. Treat the features in this preview as expected contents until the Apache Iceberg project publishes final release notes.
No. Iceberg 1.12 expands support for V3 features such as geospatial types and Variant, but Spark does not create V3 tables by default in this release.
The largest changes are the removal of Spark 3.4 support, removal of position deletes with row data, removal of scheduled deprecated APIs, and removal of older S3 signer classes and properties.
Test REST authentication built on the new AuthManager API, validated FileScanTask construction, metadata path handling, GCS host configuration, encrypted file interoperability, and DataFusion 54 compatibility.
For a deeper treatment of the table format, download Apache Iceberg: The Definitive Guide by Tomer Shiran, Jason Hughes, and Alex Merced, free from Dremio.
To see supported Iceberg features and upgrade syntax, explore the Dremio Apache Iceberg documentation.
Deploy agentic analytics directly on Apache Iceberg data with no pipelines and no added overhead.
Editor’s note, September 2026. This post was published in September 2023 and some product details have changed since. Nessie is still available and self-deployable under the Apache-2.0 licence, and it remains the clearest implementation of catalog-level branching. It is not an Apache Software Foundation project, and its development has slowed considerably. For how the current […]
With its capabilities in on-prem to cloud migration, data warehouse offload, data virtualization, upgrading data lakes and lakehouses, and building customer-facing analytics applications, Dremio provides the tools and functionalities to streamline operations and unlock the full potential of data assets.
This is Part 15, the final article of a 15-part Apache Iceberg Masterclass. Part 14 covered hands-on Dremio Cloud. This article covers the three migration strategies and how to execute a zero-downtime migration using the view swap pattern. Most organizations do not start with Iceberg. They have years of data in Hive tables, data warehouses, CSV files, databases, […]