The Release of Apache Polaris 1.3.0 (Incubating): Improvements to catalog federation, handling non-Apache Iceberg datasets and more

Apache Polaris 1.3.0-incubating shipped in January 2026 and represents a meaningful step forward for teams building open lakehouse architectures. This release focuses on three practical needs that data engineers and architects consistently raise: visibility into table usage, tighter and more flexible authorization, and the ability to manage more than one table format through a single catalog.

Polaris continues to position itself as a REST-based catalog built around Apache Iceberg, but the scope of the project has expanded. With version 1.3.0, Polaris moves closer to being a general-purpose catalog and governance layer that works across engines, clouds, and storage systems. The changes in this release are not cosmetic. They affect how operators observe production workloads, how security teams define policy, and how platform teams think about catalog consolidation.

One of the most visible additions is native Iceberg metrics reporting. For the first time, Polaris can accept and process query-level metrics sent by compute engines through the Iceberg REST API. These metrics include details such as rows scanned, bytes read, and commit activity. Instead of treating the catalog as a passive metadata store, Polaris now becomes an active source of operational signals. This matters for teams that need to understand table access patterns, validate governance controls, or trace performance issues back to specific datasets.

Security and governance also receive a major upgrade. Polaris 1.3.0 introduces integration with Open Policy Agent, allowing authorization decisions to be handled by an external policy engine. This makes it possible to express access rules that go beyond static roles and align Polaris with policy systems already used elsewhere in the data platform.

At the same time, the project expands its reach beyond Iceberg. Generic tables, first introduced as an experimental feature, are now generally available. Polaris can reliably catalog tables stored in other formats, including Delta Lake and Hudi, alongside Iceberg tables. For architects trying to reduce the number of metadata systems in their stack, this change is significant.

The rest of this post walks through these changes in detail and explains what they mean in practice for production data platforms.

Iceberg metrics turn the catalog into an operational signal

A major theme of the 1.3.0 release is observability. Polaris now implements Iceberg metrics reporting through the Iceberg REST catalog API, which allows compute engines to push execution metrics back to the catalog. This closes a long-standing gap between query engines and metadata services.

In earlier releases, Polaris tracked schema, snapshots, and table locations, but it had no native view into how tables were actually used. With 1.3.0, engines such as Spark, Flink, or Trino can report metrics for reads and commits as part of normal table operations. These metrics include values like rows read, bytes scanned, files touched, and commit counts. For data engineers, this creates a new way to answer basic questions that previously required stitching together logs from multiple systems.

Polaris processes these metrics through a pluggable reporting framework. The simplest option logs metrics directly to the Polaris service logs when the appropriate logger is set to INFO. This makes it easy to validate that metrics are flowing without adding new infrastructure. For teams that want more durable or queryable data, Polaris can persist metrics internally or emit them as events that downstream systems can consume.

This design matters because it keeps Polaris flexible. Some teams want lightweight visibility for debugging. Others want long-term retention for audits, usage analysis, or chargeback models. Polaris does not force a single approach. Operators can select one reporting mode or combine several, depending on how metrics fit into their platform.

The shift toward observability also shows up in Polaris system endpoints. Legacy health and metrics endpoints have been removed in favor of standardized Quarkus endpoints. Health checks now live at /q/health, and system metrics are exposed at /q/metrics. This aligns Polaris with common monitoring practices and simplifies integration with tools like Prometheus. For production deployments, the result is fewer custom adapters and a clearer operational model.

Together, these changes reposition Polaris from a passive catalog into an active part of the data platform. The catalog now reflects not only what data exists, but also how that data is accessed and modified over time.

Externalized authorization and tighter control over federated access

Security changes in Polaris 1.3.0 focus on two related areas: how access decisions are made and how credentials are issued in federated environments. Both areas reflect a shift toward clearer separation of concerns and stronger control at the catalog layer.

The most visible security addition is native integration with Open Policy Agent. Polaris can now delegate authorization decisions to an external OPA service instead of relying only on its built-in role model. When OPA is enabled, Polaris sends each request, along with contextual details such as the acting principal, requested operation, and target resource, to an OPA policy endpoint. The policy engine evaluates that input and returns an allow or deny decision.

For data platform teams, this opens the door to more expressive policies. Access rules no longer need to be limited to static role assignments. Policies can incorporate attributes, namespaces, table properties, or environmental context. A team can express rules like restricting write access to certain schemas, blocking access based on data classification, or applying different controls in staging versus production. Since policies live in OPA, they can be versioned, tested, and shared with other systems that already rely on the same policy engine.

This change also clarifies responsibility boundaries. Polaris continues to handle identity, request routing, and enforcement, while OPA becomes the source of truth for authorization logic. That separation reduces pressure to customize the catalog itself and makes governance changes safer to roll out.

Federated catalog support also sees important security refinements. Polaris now supports credential vending for federated catalogs, which allows it to issue short-lived credentials when a query engine needs to access data stored outside the local catalog. This removes the need to distribute long-lived cloud credentials to every engine and centralizes access control in one place.

To reduce risk, Polaris applies additional checks before vending credentials. Administrators can restrict which storage locations are eligible, and Polaris will refuse to issue credentials for remote tables that fall outside approved paths. Support for AWS Signature Version 4 authentication further improves compatibility with cloud-native services that require signed requests.

Taken together, these changes make Polaris a more trustworthy control point in multi-catalog and multi-cloud architectures. Authorization logic becomes more flexible and auditable, while credential handling becomes more centralized and constrained. For architects designing shared data platforms, these capabilities reduce the surface area for mistakes and bring governance closer to where metadata already lives.

Broader table coverage and practical operational changes

Polaris 1.3.0 also expands what the catalog can represent. Generic tables are now generally available after earlier releases treated them as experimental. This change allows Polaris to catalog non Iceberg tables in a stable and supported way. Formats such as Delta Lake, Hudi, and simple file based tables can now live alongside Iceberg tables in the same catalog.

For data engineers, this reduces fragmentation. Many platforms already run more than one table format, often for historical or tooling reasons. Before this release, teams often kept separate metastores for different formats. With generic tables, Polaris can act as a single catalog entry point, even when the underlying storage and format differ. The catalog stores the table location and format, and engines that understand that format can resolve and read the data through Polaris.

This capability does not blur the line between formats. Iceberg tables still use Iceberg specific APIs and semantics. Generic tables follow a separate path designed for simpler metadata needs. The benefit is consolidation without forcing premature migrations. Architects can plan format transitions over time while presenting a consistent catalog surface to users and tools.

Operationally, the 1.3.0 release includes several changes that improve day to day management. Kubernetes deployments benefit from updates to the Helm chart. Configuration changes now trigger automatic pod restarts through checksum annotations, which removes a common source of drift and manual intervention. Teams running Polaris in containerized environments gain a safer and more predictable deployment flow.

The Polaris CLI also sees improvements. A new flag allows operators to disable STS usage when working with S3 compatible storage systems that do not support temporary credentials. This simplifies deployments that rely on object stores outside of AWS while keeping the same catalog workflows.

Some changes in this release require attention during upgrades. The legacy persistence layer based on EclipseLink has been removed after a long deprecation period. Most users will not notice this change, but any custom deployments that depended on the old layer must migrate. The default request ID header has also changed to a more common name, which may affect logging or tracing integrations that rely on the previous header. Health and metrics endpoints have moved to standardized paths and must be updated in monitoring systems.

Taken together, these changes show a project that is tightening its foundations while expanding its scope. Polaris 1.3.0 improves visibility through metrics, strengthens governance through externalized policy, and broadens catalog coverage through generic tables. For data engineers and architects building open lakehouse platforms, this release moves Polaris closer to being a central and reliable control plane for metadata, access, and observability.

You can try these ideas in practice with Dremio’s free trial. Dremio Catalog is built on Apache Polaris and gives you a simple way to explore these features. You can start at dremio.com/get-started.