On behalf of the Apache Polaris community, we're happy to share the release of version 1.5.

Building on the momentum of 1.4's security and multi-tenancy improvements, version 1.5 makes Polaris's authorization model truly pluggable, expands its federation reach to new catalog backends and provides meaningful quality-of-life improvements for operators managing Polaris in production.

Let's take a closer look at what's new and why it matters for users.

What to expect in Polaris 1.5

Here is what you can expect in the latest version.

Authorization becomes pluggable

The most significant architectural change in Polaris 1.5 is the refactoring of the authorization layer into a fully pluggable model. In previous releases, Polaris supported Open Policy Agent (OPA) as an external authorizer alongside its built-in role-based access control (RBAC) system.

In 1.5, the Authorizer SPI has been restructured with new request-based interfaces, including AuthorizationRequest, AuthorizationDecision and a request-scoped RequestAuthorizationContext. These interfaces now cleanly separate the authorization decision from Polaris's internal principal resolution, meaning that external authorizers no longer need to understand or depend on Polaris-native RBAC concepts to make access decisions.

The immediate payoff for users is seen in the new support for Apache Ranger™ (Beta). Organizations that already use Ranger to manage access policies across their data platform can now apply those same policies to Polaris-managed Iceberg tables without duplicating configuration or maintaining parallel systems. Ranger joins OPA as the second external authorizer, and the pluggable SPI means the community can expect more integrations going forward.

On the GCP side, federated catalogs connecting to GCS-backed storage can now use Iceberg's GoogleAuthManager for credential pass-through. Rather than relying solely on OAuth, operators can adopt an end-user credentials approach where Polaris vends storage credentials directly. This gives teams more flexibility in how authentication flows work for GCP-hosted tables.

Federation reaches further

Polaris's role as a universal catalog gateway continues to grow. Version 1.5 adds BigQuery Metastore federation, enabling Polaris to serve as a unified Iceberg REST catalog interface on top of tables managed in BigQuery Metastore. For engines that speak the Iceberg REST protocol, such as Apache Spark™, Apache Flink®, Trino and others, this is transparent. They connect to Polaris the same way they always have, and Polaris handles the translation to BigQuery Metastore behind the scenes without any engine-side configuration changes required.

Equally important is the expansion of credential vending to the Generic Table API. The new Polaris-Generic-Table-Access-Delegation header and storage credentials in the load response extend Polaris's secure, short-lived credential model beyond Iceberg tables. If you're managing Delta Lake, Apache Hudi™ or Apache Paimon™ tables through the Generic Table API, the spec now defines how engines will access those tables using Polaris-vended credentials rather than maintaining their own long-lived storage keys. The implementation will follow in a future release, but the specification work is a meaningful step toward making Polaris format-agnostic in practice, not just in theory.

A CLI built for operators

The Polaris CLI has been an area of steady investment, and 1.5 offers commands that transform it from a basic CRUD tool into something genuinely useful for day-to-day operations. The tables summarize command provides a quick overview of a table, including schema, statistics and policies, while find offers fuzzy search across all identifiers. Together, these commands acknowledge that operators need to navigate and understand their catalog, not just mutate it.

Event system: Flexible and efficient

The event system also gets a meaningful upgrade. Polaris now supports multiple event listener plugins simultaneously via the polaris.event-listener.types configuration. Previously limited to a single listener, operators can now route events to multiple destinations at once, e.g. logging to a file while simultaneously streaming to an external audit system, or feeding events to both a metrics pipeline and a webhook.

Each listener can also subscribe to only the event types or categories it cares about. A security audit listener only receives access-control events; a metrics listener only gets commit events. Beyond reducing noise, this has a performance benefit: PolarisEvent objects aren't even constructed if no listener is subscribed to that event type.

Performance and correctness improvements

Several changes in 1.5 address real production pain points in both the JDBC and NoSQL persistence backends.

The JDBC persistence layer previously used coarse-grained synchronized methods that serialized all requests across all realms. This has been replaced with per-realm read/write locks: DDL operations take a write lock on the affected realm, while normal requests share a read lock. For multi-tenant deployments, unrelated realms no longer block each other, resulting in significantly improved throughput.

Iceberg REST Catalog credential vending no longer requires a round-trip to the object store to read metadata.json. Instead, it directly uses the entity state to determine the locations for credential vending. Users can expect significant latency improvements in the credential vending process.

A critical performance fix resolves an issue where create_namespace operations could exceed 30 seconds under load, causing 504 Gateway Timeouts. The root cause was permission check queries performing full table scans on grant_records. Targeted database indexes eliminate the full scans and bring latency back to normal.

For the NoSQL backend, a series of correctness fixes ensure the authorization state stays consistent. Phantom grants for dropped entities no longer appear in resolution queries, stale grants with deleted grantees are filtered out, grant entities are revalidated before any modification, and ACL entries are properly filtered by direction. The net effect: Access control decisions are always based on current, valid state.

Breaking changes to know about

A few breaking changes to be aware of when upgrading:

• ExternalCatalogFactory renamed to FederatedCatalogFactory: The interface has been renamed and its method signatures extended with a catalogProperties parameter for proxy and timeout settings.
• Credential expiration enforcement: ConnectionCredentials.of() now throws an exception if more than one expiration timestamp is present in the credentials map.
• Entity name validation: Names submitted to the REST layer are rejected with HTTP 400 if they are empty, contain a /, or have leading or trailing whitespace. Clients that previously created such entities should rename them before upgrading.

What's next

Apache Polaris 1.5 advances the project on the dimensions that matter most for production adoption: flexible security, broad interoperability and operational ergonomics. The pluggable authorization model opens the door to enterprise governance integrations. Expanded federation and credential vending make Polaris relevant beyond Iceberg alone. And the CLI and performance improvements reflect a project that's paying attention to what operators actually need.

This release wouldn't be possible without the contributors, reviewers and testers across the community. If you'd like to get involved, check out the Polaris GitHub repo, browse the open issues and join the conversation.

Give Polaris 1.5 a try and let us know what you think.

Apache® and Apache Polaris are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries.