The Apache Iceberg™ community has officially released version 1.11, and there are a lot of new changes for users to look forward to.

Excitingly, this release marks a turning point for the REST catalog protocol, transforming it from a simple metadata API into something much closer to a full-featured catalog service. Alongside that, users will find meaningful performance improvements, production-ready encryption and the first foundational pieces of the v4 Table Spec.

Let's take a closer look at what shipped as part of Apache Iceberg version 1.11 and why it matters.

The REST catalog grows up

A major theme that defines Iceberg 1.11 is the maturation of the REST catalog protocol. Multiple features landed together that collectively make the REST catalog smarter, more efficient and more reliable for production workloads.

• Remote scan planning: The headline addition is remote scan planning. Until now, every client, whether that was Apache Spark™, Apache Flink®, Trino or anything else, had to download manifest lists and manifests to determine which data files to read. For large tables, that meant pulling significant metadata across the network before a single row could be processed.
  
  In 1.11, the catalog server can perform that planning work itself and stream back only the relevant file scan tasks. This reduces client-side memory consumption, speeds up job startup and opens the door for catalog providers to apply server-side optimizations, such as caching or prefiltering entirely invisible to the engine. Spark is already wired into this new API, so users with a compatible REST catalog will benefit automatically.
• Freshness-aware table loading: Complementing remote scan planning is freshness-aware table loading via ETag-based caching. When a client requests metadata for a table it already knows about, the server can return a simple 304 "not modified" response instead of retransmitting the full payload. For interactive workloads and tight read loops, this eliminates a substantial amount of redundant network traffic.
• Idempotency key support: Production reliability gets a boost with idempotency key support. The REST spec now defines a standard Idempotency-Key header so that retried mutations such as commits, creates or drops, won't accidentally execute twice. Network timeouts are a fact of life in distributed systems, and without idempotency key support, a retried commit could produce duplicate snapshots or conflicting state. The spec now handles this cleanly, with well-defined rules for key lifetimes and finalization semantics.

Faster queries, smoother operations

Several changes in 1.11 make Iceberg measurably faster at query time and more reliable in long-running production environments.

• LIMIT pushdown: When your query includes a LIMIT clause, Iceberg now stops scanning after enough rows are found rather than reading all matching files. For exploratory queries against large tables, this can reduce I/O from terabytes to megabytes. It's available across Spark versions shipped with 1.11.
• Vectorized reads: Users will find that vectorized reads now cover three additional Parquet encodings that were previously falling back to row-at-a-time processing: BYTE_STREAM_SPLIT, DELTA_LENGTH_BYTE_ARRAY and DELTA_BYTE_ARRAY. This is especially impactful for scientific and ML data sets that use float/double columns with BYTE_STREAM_SPLIT for better compression.
• Smarter snapshot expiration: On the maintenance side, snapshot expiration got better. Previously, the process scanned all manifests to determine which files to delete. Now it skips manifests still referenced by live snapshots, which can reduce expiration time by orders of magnitude for tables with many snapshots and large manifest lists.
• Unique-table-location catalog property: For operational safety, the new unique-table-location catalog property appends a UUID to storage paths, preventing a real data loss scenario where DeleteOrphanFiles could remove data belonging to a renamed table. And both AWS and GCP now proactively refresh credentials on a schedule rather than waiting for a 403 error, eliminating transient failures in long-running streaming jobs.

Encryption goes production-ready

Iceberg's encryption story has been building across several releases, and 1.11 is where it all comes together. Manifest lists, the top-level metadata files, are now encrypted. Key encryption keys auto-rotate on expiration. The Hive catalog is the only catalog that is fully integrated. And with Azure Key Vault now supported alongside AWS KMS and GCP, these three major cloud providers are covered for envelope encryption key management.

In short: Users can now encrypt an entire Iceberg table using standard cloud KMS infrastructure. No more gaps, no more workarounds.

New spec changes

All Iceberg users are eager to hear the latest on the v3 Table Spec and what the future holds across all of the project's specifications.

UDFs and geospatial

To start, 1.11 introduces two entirely new spec-level capabilities.

The SQL UDF Specification defines how user-defined functions are stored in Iceberg catalogs. UDFs are versioned, support multiple SQL dialects (Spark, Trino and others) and are portable across engines. This is the first time function management has been brought into the catalog layer, so it's a meaningful step toward making Iceberg catalogs a complete representation of your data platform's logic, not just its tables.

Geospatial bounding box types also land in Iceberg's type system. You now have native bounding box types and an INTERSECTS predicate, enabling spatial partition pruning and file skipping for geospatial workloads. This was previously impossible without external tooling, and it unlocks GIS and location analytics use cases directly on Iceberg tables.

ReferencedBy in LoadTable API

In this version, the Iceberg REST spec started supporting ReferencedBy along with the full reference chain. This opens the path for DEFINER views in Iceberg REST spec along with improved auditability.

Laying the foundation for v4

While v3 is just being adopted, the community is already heads-down defining the next iteration of the table spec with v4. Although users won't see v4 in their day-to-day workflows yet, 1.11 introduces the foundational types that will underpin it. Core abstractions like TrackedFile, TrackingInfo, ContentInfo and ManifestStats define the building blocks for v4's adaptive metadata tree, which is a fundamentally new way of tracking files that the community will build on in future releases.

Alongside this, the new FormatModel abstraction replaces hardcoded file format handling with a pluggable interface. Parquet, ORC, Avro and Arrow each implement a FormatModel contract, making it significantly easier to add new formats or customize read/write behavior. Both Spark and Flink have already migrated to this new API.

Two additional infrastructure pieces, a Content Stats API for file-level statistics and a Partition Stats Scan API for composable partition-level queries, provide richer metadata for future query planning improvements.

Looking ahead

Apache Iceberg 1.11 is a release that moves the project forward on multiple fronts simultaneously. The REST catalog is no longer just a metadata endpoint — it's becoming an intelligent service layer. Encryption is production-complete. Performance optimizations reduce both query latency and operational overhead. And the groundwork for Format v4 signals where the project is headed next.

This release wouldn't be possible without the many contributors, reviewers and testers across the community. If you'd like to get involved, check out the Iceberg GitHub repo, browse the open issues and join the conversation shaping the next generation of open table formats.

Give Iceberg 1.11 a try, check out the new features and share your feedback. We can't wait to see what you build with it.