Apache Iceberg 1.12.0: What Data Engineers Should Know Before Upgrading
Apache Iceberg 1.12.0 arrived October 5, 2026. Explore Variant, geospatial types, deletion vectors and breaking compatibility changes.
Published-source date: October 5, 2026
A data lake is easy to start and surprisingly difficult to maintain. Storing files is not the same as managing a table whose schema changes, whose records are updated, and whose readers must agree on which data belongs to a particular snapshot.
Apache Iceberg 1.12.0, released on October 5, 2026, continues to address those problems. The project reports 777 commits by 142 contributors since version 1.11.0. Its release notes cover semi-structured Variant data, geospatial types, deletion vectors, catalog improvements, and engine compatibility. For a production team, the last item may matter as much as the first four.
Iceberg is a table format, not just another file type
Parquet stores data in column-oriented files. Iceberg organizes a logical table using metadata and snapshots so that compatible engines can work with the same evolving dataset. Its role includes schema evolution, consistent reads, and table maintenance. It does not eliminate the need for storage security, data quality checks, or cost monitoring.
Think of a table as more than a directory. The data files are the ingredients; metadata tells the query engine which ingredients belong to the current recipe. A new snapshot can represent a changed table state without every reader independently guessing which files are valid.
What changed in version 1.12.0?
| Area | Release development | Why it may matter |
|---|---|---|
| Variant | Faster unshredded reads in Spark and broader shredded writes | Working with flexible JSON-like records |
| Geospatial | Additional read/write support | Location-based analytical datasets |
| Deletion vectors | Continued delete-handling improvements | Large tables with row-level changes |
| REST catalog | Protocol and operational refinements | Interoperability between services |
| Engine support | Additions and removals | Preventing broken pipelines during upgrades |
Variant allows semi-structured values in an analytical table. Iceberg 1.12.0 uses a vectorized Parquet path for certain unshredded Variant reads in Spark. It also expands shredded Variant writing beyond Spark. Shredding means storing selected fields in typed columns to support efficient access. That can help when a query repeatedly needs the same fields, but it does not guarantee every workload becomes faster.
Deletion vectors and correctness
Large tables often need row-level deletions. Rewriting entire files can be expensive. Deletion vectors offer another way for supported systems to represent removals. However, a reader that does not understand the table's active features may produce incorrect results or refuse to read the table.
Before enabling a new table feature, list every engine that reads or writes the dataset. Include scheduled jobs, notebooks, streaming consumers, dashboards, and disaster-recovery tools. A successful Spark test does not prove that an older connector is compatible.
Breaking changes to check now
The official release notes say Spark 3.4 support was removed; listed supported Spark versions include 3.5, 4.0, and 4.1. Flink 2.0 support was removed; listed supported versions include 1.20, 2.1, 2.2, and 2.3. The release also removes or replaces various APIs.
For teams upgrading from 1.11.0, the correct first step is a compatibility matrix, not a production deployment. Record the engine version, connector version, table format version, and required operations for every workflow.
A controlled migration plan
- Create an inventory of tables, readers, writers, and table-format features.
- Check removed APIs and unsupported engine versions.
- Copy a representative dataset into a staging environment.
- Compare row counts, null rates, aggregates, and delete behavior.
- Test schema evolution, failed commits, and streaming restarts.
- Roll out gradually with data-quality and latency monitoring.
For a beginner, learning snapshots, manifests, catalogs, and schema evolution is a better investment than memorizing release-note jargon. Those concepts will remain useful even after the next version ships.
FAQ
Is Apache Iceberg a standalone database server?
No. It is an open table format and ecosystem used with compatible compute engines and catalogs.
Does upgrading the library automatically upgrade every table's features?
No. Software versions, table-format versions, and enabled features are different concerns.
Is Variant always better than a fixed schema?
No. Stable typed schemas are often simpler. Variant is useful when semi-structured data justifies the trade-offs.