What's New in Apache Polaris™ 1.6:

On behalf of the Apache Polaris community, we're excited to announce version 1.6. Where 1.5 focused on making authorization pluggable and expanding federation reach, 1.6 turns inward — hardening security defaults, enabling live migration workflows and bringing the event system to production-grade maturity. It's a release shaped by what operators encounter running Polaris at scale.

Let's walk through what's new.

Security hardening across the stack

Polaris 1.6 delivers a series of security improvements that collectively tighten the token lifecycle, credential handling and input validation surface.

New JWT issuer validation closes a token confusion gap. Previously, any token signed with a valid key was accepted regardless of its issuer claim. Now, tokens must carry the expected polaris issuer, and tokens from other services that happen to share signing infrastructure are rejected outright. In multi-service deployments where key material is shared or rotated across systems, this is a meaningful defense-in-depth measure.

Access token redaction removes bearer tokens from authentication logs. Previously, failed auth attempts at WARN level would write the full token to logs via PolarisCredential.toString(). In environments where log access is broader than credential access, this closes a token leakage path that previously existed in WARN-level auth logging.

Configurable AWS STS role session names improve auditability for AWS-integrated deployments. The new SESSION_NAME_FIELDS_IN_SUBSCOPED_CREDENTIAL feature flag lets operators compose STS session names from an ordered list of fields such as realm, catalog, namespace, table, principal—producing structured identifiers. Session names are sanitized and proportionally truncated to the AWS 64-character limit. The result is CloudTrail entries that tell you exactly which Polaris principal accessed which table, without parsing opaque session IDs.

Finally, stricter entity name validation builds on the basic rules introduced in 1.5. In addition to rejecting empty strings, names with / and leading/trailing whitespace, the REST layer now also rejects names consisting of . or .., names containing control characters, and names with characters like \:*?"<>|#+. If you have existing entities with these characters, you'll need to rename them before upgrading.

Zero-downtime catalog migrations

The most requested workflow improvement in 1.6 is register table with overwrite semantics. The register table endpoint now accepts overwrite=true, allowing an existing table's metadata pointer to be updated to a new location without dropping and recreating the table.

In production, dropping a table means losing its grants, policies, and any client references. Teams performing metadata migrations—e.g. moving from another catalog system, updating pointers after major compaction, or swapping between staging and production metadata—previously had to orchestrate a careful drop-register-regrant sequence with downtime. With overwrite semantics, the pointer swap is atomic. Grants and policies stay intact. Clients don't need to reconnect.

A new REGISTER_TABLE_OVERWRITE authorization operation (mapped to TABLE_FULL_METADATA) ensures the overwrite path has explicit, auditable access control separate from normal registration.

Alongside this, view registration brings parity between tables and views. Views can now be imported into Polaris catalogs without recreating them from scratch which is useful when federating views from external systems or migrating between Polaris deployments.

A production-ready event pipeline

Polaris 1.5 introduced multi-listener support and global secure-by-default sanitization. Version 1.6 completes the event system's journey to production readiness with three changes that address reliability, ordering, and security.

Event listeners now execute on a dedicated thread pool, fully decoupled from the request lifecycle. In the past, a slow or blocking listener could hold up the catalog operation that triggered it. Now, events are dispatched asynchronously to a configurable executor (polaris.event-listener.executor.pool-size and queue-size). Catalog operations complete at catalog speed regardless of listener behavior. Note for upgraders: the original request's CDI context is no longer propagated to listeners — if your listeners relied on request-scoped CDI beans, they'll need to manage their own scope going forward.

Ordered per-listener delivery guarantees that events arrive at each listener in the order they occurred. This is essential for audit and compliance listeners where a "table created" event must precede a "table updated" event.

The event persistence overhaul restructures how events flow through the system. All events now pass through a universal routing pipeline with global secure-by-default sanitization. Sensitive fields like credentials, tokens and PII are redacted at the pipeline level before reaching listeners (including custom plugins that implement the listener interface). You no longer need to trust that every listener implementation handles sensitive data correctly; the pipeline handles it for them.

Together, these changes mean the event system is now production ready for regulated environments: events are ordered, sensitive fields are redacted at the pipeline level and listeners are fully decoupled from catalog operations.

Ecosystem and operations

Polaris 1.6 keeps pace with the broader data ecosystem while addressing operational pain points that surface in long-running production deployments.

One of the biggest changes in 1.6 is a new Apache Spark™ 4.0 client, giving Spark 4.0 users top-level Polaris integration for catalog operations, credential vending and table management. An upgraded Python client adds Python 3.14 support, tracking the latest CPython release.

The CLI gains REPL mode, an interactive session where operators can issue multiple commands without reauthenticating or respecifying connection parameters. Combined with the new CLI commands added in 1.5, this makes the CLI a practical tool for exploration and debugging, not just scripted automation.

On the operations side, a critical Azure SAS token fix resolves a long-standing issue where SAS tokens were hardcoded to a 1-hour duration regardless of configuration, meaning that long-running Spark or Apache Flink® jobs on Azure would fail mid-execution with expired credentials. With the fix, now they honor the operator-configured duration. The token broker has also been optimized to build JWT Algorithm and JWTVerifier objects once per realm rather than on every request, reducing per-request overhead.

For Kubernetes deployments, the Helm chart adds hostUsers support for rootless container environments and a dedicated maintenance deployment for running background maintenance tasks separately from serving pods. On the maintenance API side, MaintenanceService.performMaintenance() now requires an explicit overrideRunId argument, and the admin tool rejects new runs when the latest is still unfinished unless --supersede-run=<run-id> is passed—a guardrail against accidental concurrent maintenance in large deployments.

Looking ahead

Apache Polaris 1.6 is a release focused on production confidence. Security hardening closes gaps that matter in multi-tenant and multi-service environments. Register-with-overwrite unlocks migration workflows that were previously painful or impossible without downtime. And the event pipeline is now ready for the compliance and audit use cases that enterprise adopters need.

Thank you to everyone who contributed code, reviews, testing and feedback. If you'd like to get involved, check out the Polaris GitHub repository and join the conversation.

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

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