Apache Iceberg 1.12.0: Removals, Variant and Geospatial

Apache Iceberg 1.12.0 is a release for teams that run the table format in production. According to the project's release page, it shipped on September 29, 2026, and it does three things at once: it drops support for older engines, it removes a long list of deprecated APIs, and it extends the format toward geospatial data, semi-structured "variant" columns, and the still-evolving v4 specification. Most of the changes are incremental, but several will require action before an upgrade.

What is in the release

The Apache Iceberg release notes describe 1.12.0 as a mix of bug fixes and new features. Runtime JARs are published for Spark 4.1, 4.0 and 3.5, for Flink 2.3, 2.2, 2.1 and 1.20, and for the AWS, GCP and Azure bundles. The project's GitHub release page lists the same release with a date of September 30, one day later than the September 29 date shown on the Apache Iceberg release page. This article uses the date listed on the project's official release page.

Breaking changes first

For operators, the removals matter more than the additions. The release notes say Spark 3.4 support and Flink 2.0 support are gone, and that a range of deprecated APIs have been removed. Examples include Spark filter, table-utility and configuration helpers, the Flink RewriteDataFiles.Builder.filter(Expression) method, the REST namespace encoding helpers, a HadoopFileIO constructor and the DataReader class, which has been replaced by PlannedDataReader. Deprecated partition-statistics read functionality, deprecated AWS S3 signer classes and properties, and members of the Kafka Connect and BigQuery integrations have also been removed. Position delete files that contain row data have also been removed.

Three behaviour changes are worth checking in test environments:

• The toString() output for geometry and geography types now always includes the resolved coordinate reference system, so geometry prints as geometry(OGC:CRS84). Any code or tests that compare type strings could break.

• The default AWS SDK HTTP client has moved to Apache HttpClient 5. Teams that supply AWS dependencies themselves must switch from apache-client to apache5-client.

• The REST client now retries POST requests that carry an Idempotency-Key on retriable errors (408, 500, 502, 503 and 504).

Variant and geospatial data

The feature work centres on data types that do not fit neatly into flat tables. On the variant side, the release adds vectorized Parquet reads for unshredded variant columns in Spark 4.0 and 4.1, shredded-variant writing in Flink, Parquet variant shredding for generic record writes in Kafka Connect, and hardening of variant binary parsing against malformed input. VariantType has also been added to the REST specification.

On geospatial data, the notes list single-value binary serialization for geometry and geography, read and write support in Avro, well-known-binary values in Parquet, and geometry and geography type mapping in Spark 4.1. Taken together, these suggest that Iceberg tables are being prepared to hold location and JSON-like event data without leaving the table format, although the notes describe the plumbing rather than performance results, and no benchmarks are given.

Streaming and maintenance

Flink users get support for Flink 2.2 and 2.3, and a ConvertEqualityDeletes maintenance task that converts equality deletes into deletion vectors, integrated with IcebergSink. Equality deletes are a common product of streaming upserts, and converting them is intended to make later reads cheaper, though the notes do not quantify the effect. The Flink changes also add reading of Iceberg views in SQL, along with CREATE VIEW, DROP VIEW and ALTER VIEW RENAME in FlinkCatalog, a slot sharing group option for the dynamic sink, and fixes for duplicate commits after a job ID change and for a thread and memory leak.

The Kafka Connect sink now surfaces commit failures instead of silently swallowing them, adds bounded retries for transient commit exceptions and a metric for partial commit failures, and commits offsets only when they increase. For anyone who has debugged a sink that appeared healthy while commits were failing, that visibility is arguably the most useful change in the release.

Spark gets a Hilbert-curve clustering strategy for rewrite_data_files in Spark 4.1, a sort_by parameter for rewrite_manifests, session-level split-size overrides, an ignore_missing_files option for the migrate and snapshot procedures, and a rest-catalog-purge property that delegates DROP TABLE PURGE to REST catalogs.

The v4 specification and the catalog layer

The release continues groundwork for the next version of the table specification. Notes list v4 manifest reading and writing, relative path resolution and utilities for relativizing locations, extended v4 deletion vectors, and new specification text for content stats, expressions, finer-grained read restrictions in loadTable and relative paths. These are building blocks; the notes do not say when v4 will be declared complete, and they do not describe any migration path.

The REST catalog protocol, which is increasingly how engines talk to Iceberg catalogs, gains an unregister-table endpoint, list and load function endpoints, a labels field for catalog metadata, and a formalized remote signing configuration. A new RepairTable action interface is also added to the API. The GitHub release notes additionally list encryption work, including encrypting file IO and preserving deletion vector encryption metadata, and the removal of dangling delete files through a scan-based action.

What data teams should do

A sensible upgrade plan follows from the notes. Check engine versions first: anyone still using Spark 3.4 or Flink 2.0 will need to upgrade before moving to Iceberg 1.12.0. Search code for the removed classes and constructors listed above, test any string comparisons on geospatial type names, and verify AWS dependency choices before moving to the new HTTP client. Teams that run streaming upserts with equality deletes should test the new conversion task on a copy of a busy table before relying on it.

The notes are long, and this article covers only a selection of the entries; readers should consult the full release notes before upgrading production tables.

What to watch next

The signals to follow are how quickly engines and managed services adopt 1.12.0, whether variant and geospatial support show up in real workloads with measured gains, and how the v4 specification work progresses. Releases like this rarely make headlines, but the quiet pruning of old APIs and the steady widening of supported data types show where open table formats are heading: toward holding more kinds of data, with more of the maintenance handled inside the format itself.