Apache Iceberg 1.11.0 Ships With Full Encryption, Spark 4.1 Support, and Deletion Vectors for Flink
Apache Iceberg 1.11.0 arrives with at-rest encryption across all table files, Spark 4.1 and Flink 2.1 compatibility, and Deletion Vector write support for Flink.
Overview
Apache Iceberg 1.11.0 was released on May 20, 2026, bringing the open table format a package of features that advance coverage of the V3 specification: at-rest encryption extended to manifest list files, Spark 4.1 and Flink 2.1 compatibility, Deletion Vector write support in Flink, and a new catalog property to prevent a class of data-loss bugs in table rename workflows. As previously reported, the V3 specification and ecosystem adoption were central themes at Iceberg Summit 2026 in April; 1.11.0 is the reference library release that makes those V3 features available to Java-based engine integrations.
What We Know
Manifest List Encryption Completes the At-Rest Encryption Layer
The most significant security addition in 1.11.0 is manifest list encryption, which closes the last gap in Iceberg’s at-rest encryption implementation. According to the encryption documentation, “Iceberg table encryption protects confidentiality and integrity of table data in an untrusted storage. The data, delete, manifest and manifest list files are encrypted and tamper-proofed before being sent to the storage backend.” The metadata.json file does not contain data or stats, and is therefore not encrypted.
Encryption is currently supported in the Hive and REST catalogs for tables with Parquet and Avro data formats. Two parameters are required to activate encryption: a catalog property specifying the KMS — either encryption.kms-type for pre-defined KMS clients (aws, azure or gcp) or encryption.kms-impl for a custom client — and a table property encryption.key-id that identifies the master key stored in the KMS.
Companion to the manifest list encryption is automatic rotation of key encryption keys. As the PR explains, “the NIST SP 800-57 document recommends setting a limit of 2 years on the crypto-period of key wrapping (encryption) keys.” The earlier implementation required manual re-wrapping procedures. The 1.11.0 solution uses the key encryption key timestamp as an AES GCM signature when wrapping manifest list key metadata; malicious timestamp tampering is detectable on decryption, and “this solution also enables automatic rotation of the key encryption keys, so the users don’t need to run manual re-wrapping procedures on their tables.”
Spark 4.1 and Performance Improvements
The release adds Spark 4.1 support, refined to track Spark 4.1.1. Notable Spark 4.1-specific work includes initial support for MERGE INTO schema evolution, allowing MERGE statements to add new columns when the source has a wider schema than the target.
The release also delivers LIMIT pushdown to the Scan for Spark 4.0 and Core. As the PR describes, the LIMIT is pushed down through the Scan and used as min-rows-requested for server-side scan planning, which is “used as a hint during server-side scan planning to not have to return more rows than necessary.”
On the lifecycle side, Spark 3.4 support is deprecated in 1.11.0, following the project’s three-major-version support window.
Flink 2.1 and Deletion Vectors
Flink 2.1 support is included in 1.11.0. As noted in the Flink 2.1 support PR, the integration removes support for Flink 1.19 to stay within the three-version maintenance window.
A more operationally significant Flink addition is Deletion Vector write support in the Flink delta write path. The PR states: “Currently, position delete in Flink only supports v2 and does not support DVs. This PR is mainly aimed at enabling DV support in Flink’s delta write.” Deletion Vectors are the V3 format’s approach to row-level deletes: compact bitmap structures stored in Puffin files that record deleted rows within a single data file, offering lower write amplification for high-frequency update workloads than the earlier V2 position delete files.
Alongside DV write support, 1.11.0 adds a Core-level safeguard for detecting and merging duplicate DVs before a commit completes. According to the PR, the problem arises when Spark’s Adaptive Query Execution (AQE) splits a data file across multiple tasks, with each task producing its own DV for the same data file. “Currently, after that commit reads would fail since the DeleteFileIndex detects the duplicates and fails on read.” The fix updates the MergingSnapshotProducer to detect and merge such duplicates before the snapshot is written.
Unique Table Locations Property
A new catalog property, unique-table-location, addresses a correctness issue in catalogs that support table renames. When enabled, a unique suffix is added to the table path so that each table has its own dedicated storage location even after a rename-and-recreate cycle.
As the PR explains, without this property, renaming a table and then creating a new one with the original name causes both tables to share the same storage location. “Such overlap can lead to: Data loss during the DeleteOrphanFilesSparkAction, which may inadvertently delete files belonging to other tables in the shared location.” The property is disabled by default to preserve existing behavior.
Spec and REST Catalog Changes
At the specification level, 1.11.0 deprecates position delete files with row data — the V2 variant that carried full row content alongside file path and row position. The deprecation formalizes the transition to Deletion Vectors as the preferred row-level delete mechanism in V3 tables.
What We Don’t Know
Encryption support is currently limited to Hive and REST catalogs with Parquet and Avro formats. Whether JDBC and other catalog backends will gain encryption support in a future release has not been announced.
With Spark 3.4 now deprecated, the active support matrix covers Spark 3.5, 4.0, and 4.1. Whether Spark 3.5 will remain supported through the 1.12.x cycle depends on upstream Spark release cadence.
Analysis
Apache Iceberg 1.11.0 consolidates features across security, engine breadth, and operational correctness. The manifest list encryption completion and automatic key rotation have direct compliance implications for regulated-data workloads, where demonstrating a complete encryption coverage of every file layer is a practical requirement.
Flink’s Deletion Vector write support is particularly significant for streaming pipelines. Before 1.11.0, Flink users writing frequent row-level updates had to fall back to V2 position delete files, which generate a separate delete file per position and accumulate metadata overhead at scale. DV support brings Flink in line with the V3 compaction model.
The unique-table-location property addresses a class of data-loss bug that has caught production deployments off guard, and the LIMIT pushdown reduces unnecessary scan work for queries that need only a sample of rows.