What’s New in Apache Polaris 1.2.0: Fine-Grained Access, Event Persistence, and Better Federation

Apache Polaris is quickly becoming the standard open catalog for Iceberg lakehouses. Version 1.2.0 brings more control, better compatibility, and early steps toward deeper observability. If you're building a lakehouse that supports multiple tools or engines, Polaris helps keep everything consistent, governed, and performant.

This release focuses on practical improvements. Teams now have more precise access controls, broader storage support, and new options for monitoring how the catalog is used. Let's look at what changed and why it matters.

What is Apache Polaris

Polaris is an open source catalog that implements the Apache Iceberg REST protocol. It manages table metadata, schema versions, and access policies across your lakehouse. Any Iceberg-compatible engine, like Spark, Flink, Trino, or Dremio, can read and write data through Polaris.

The catalog sits at the heart of an Iceberg deployment. It keeps your tables discoverable, trackable, and accessible across tools and teams. Polaris is also the foundation of the Dremio Catalog, a production-grade implementation available in cloud and self-managed environments.

For teams building open, multi-engine lakehouses, Polaris removes friction and avoids vendor lock in.

What’s New in 1.2.0: More Control, More Compatibility

Fine Grained Authorization for UpdateTable

Earlier versions of Polaris supported broad permissions, like TABLE_WRITE_PROPERTIES, to control write access. That approach worked but offered limited flexibility.

Polaris 1.2.0 introduces new granular privileges, including TABLE_ADD_SNAPSHOT, that let administrators target specific operations. You can still use the original permission groups, but now you can grant access to individual actions when needed.

This update makes it easier to delegate access without overexposing capabilities. For example, a pipeline that adds snapshots no longer needs permission to update table settings.

Event Persistence (Preview)

Polaris now supports persisting catalog events to external systems. This includes table updates, credential changes, and other operational actions.

In this release, two destinations are supported:

• JDBC-compatible databases
• AWS CloudWatch

This feature is useful for teams that want to integrate catalog activity into their existing observability stack. You can track who changed what and when, without building custom instrumentation from scratch.

Note that this feature is marked as preview. The schema may evolve in future versions, and previously stored events may become unreadable after upgrades.

Role Based Access Control for Federated Catalogs

In complex data environments, it's common to connect a Polaris catalog to one or more federated catalogs such as Hive or AWS Glue. Until now, Polaris applied access control at the catalog level. With 1.2.0, teams can enable sub-catalog RBAC to control access at the namespace or table level within federated catalogs.

This gives you tighter control over who can see or modify specific parts of a catalog, even if that catalog connects to an external system. You can now define rules that limit access to a single schema or table, instead of managing access across the entire catalog.

To use this feature, set the following property on each catalog:
polaris.config.enable-sub-catalog-rbac-for-federated-catalogs

This can be controlled globally with the feature flag:
ALLOW_SETTING_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS

By default, this flag is enabled. The feature gives platform teams more flexibility when managing large, multi-tenant catalogs that span multiple systems.

IAM Authentication for Aurora PostgreSQL

Polaris now supports connecting to Amazon RDS and Aurora PostgreSQL using IAM authentication. This removes the need to manage static database passwords and helps align with cloud-native identity and access management practices.

IAM-based authentication is especially helpful for teams running in AWS environments that want to enforce tighter security policies while reducing operational overhead.

Support for S3 Compatible Storage Without STS

Many organizations use object storage systems that are compatible with the S3 API but do not support AWS's Security Token Service. In Polaris 1.2.0, you can now connect to these systems by setting the configuration option stsUnavailable: true in your catalog storage definition.

This opens up support for additional storage providers and makes it easier to deploy Polaris in private or hybrid cloud environments.

Management API for Credential Reset

A new API endpoint has been added that allows teams to reset principal credentials through a management interface. This is controlled by the feature flag ENABLE_CREDENTIAL_RESET, which is enabled by default.

Credential resets are useful for rotating expired tokens, revoking leaked credentials, or maintaining better control over short-lived auth sessions.

API Changes and Breaking Behavior

A small but helpful change in this release affects how the Polaris API responds when creating new resources. The following endpoints now return the full created object as part of the 201 success response:

• createCatalog
• createPrincipalRole
• createCatalogRole

This improvement reduces round trips for clients that need to inspect or validate newly created resources.

There is also one breaking behavior to be aware of. By default, Polaris now blocks the creation or modification of a namespace that uses a custom location outside of its parent. This change improves catalog integrity and prevents accidental misconfiguration.

To restore the previous behavior, you can set the ALLOW_NAMESPACE_CUSTOM_LOCATION flag to true.

Deprecations Ahead

This release also starts the deprecation clock for a few items that will be removed in future versions.

• The configuration property polaris.active-roles-provider.type is deprecated and no longer has any effect.
• The /metrics and /healthcheck management endpoints have been deprecated. Use the newer /q/metrics and /q/health endpoints instead. The legacy endpoints will be removed in 1.3.0 or 2.0.0.
• The EclipseLink persistence backend, deprecated since version 1.0.0, will be removed in either 1.3.0 or 2.0.0.

If you rely on any of these features, begin planning your migration now to avoid disruptions in future upgrades.

Why This Release Matters

Apache Polaris 1.2.0 continues to make the case for a fully open, production-grade Iceberg catalog. These changes reflect real-world needs: better control, stronger security, broader compatibility, and early hooks for observability.

As Iceberg adoption grows, Polaris is becoming the default choice for teams who want to avoid vendor lock-in while building modern lakehouse infrastructure. Whether you’re using Dremio Catalog or deploying Polaris yourself, this release brings features that support scale, safety, and flexibility.

Get Started

You can try Polaris 1.2.0 today:

• Quick Tutorial to Try Apache Polaris on Your Laptop
• Download "Apache Polaris: The Definitive Guide" for Free Today
• Download binaries
• Pull the Docker image
• Browse Maven artifacts

If you want to use Polaris as part of a fully managed platform, check out the Dremio Catalog, which builds on Polaris and adds automated optimization, governance, and seamless federation across all your data sources.