Apache Polaris Releases Version 1.1.0 (Better Federation, Minio Support and more)

Download a Free Copy of "Apache Polaris: The Definitive Guide"

Apache Polaris continues to evolve as the open lakehouse catalog for Apache Iceberg, and the upcoming 1.1.0 release brings significant improvements that reflect the growing demands of modern data architectures. Developed in collaboration between Dremio and Snowflake and now an Incubating Apache community-run project, Polaris was built to bring openness, interoperability, and governance to the metadata layer of Iceberg lakehouses.

This new release deepens that vision with support for federated Hive metastores, modular catalog federation, and broader authentication and storage capabilities. It’s about more than feature additions; it’s a reflection of how organizations are scaling their Iceberg adoption and need a catalog that can grow with them.

Whether you're integrating legacy Hive systems, adopting MinIO for object storage, or rolling out secure multi-tenant deployments, Polaris 1.1.0 lays the groundwork for a more flexible, secure, and developer-friendly catalog experience. In this blog, we’ll walk through what’s new, why it matters, and how it fits into the broader goals of managing an open lakehouse at scale.

Expanded Object Storage Support: S3 Compatibility Without Compromise

Many Iceberg lakehouses rely on object storage as the foundation for scalable, cost-effective data storage. But real-world deployments often involve a mix of environments, AWS, on-premises S3-compatible systems like MinIO, and custom cloud configurations. Polaris 1.1.0 recognizes this diversity and expands its object storage compatibility to meet teams where they are.

One of the key updates is support for configuring custom S3 and STS endpoints. This allows Polaris to connect with non-AWS object stores that expose an S3-compatible API, including MinIO, Ceph, and others. Whether you're running a local development cluster or deploying across a private cloud, Polaris can now serve as the Iceberg catalog, eliminating the need for workarounds or proprietary connectors.

Path-style access for S3 is also now supported. While many newer S3-compatible services default to virtual-hosted-style URLs, some environments still require or prefer path-style addressing. By supporting both models, Polaris reduces configuration headaches and improves compatibility across diverse infrastructure.

The addition of MinIO support is particularly noteworthy. Polaris now includes comprehensive documentation and guides for getting started with MinIO, making it easier than ever to experiment with a fully local Iceberg + Polaris + object storage stack. For teams evaluating Polaris or building self-managed deployments, this significantly lowers the barrier to entry.

Combined, these enhancements make Polaris a more portable and flexible metadata solution—one that can follow your data strategy, whether you're cloud-native, hybrid, or on the edge.

Federation Grows Up: Modular, Multi-Catalog, and Ready for the Real World

As organizations build out their lakehouse platforms, they’re rarely starting from scratch. Many already have investments in legacy Hive metastores, use cases that span multiple regions or clouds, and a growing mix of data cataloging needs. Polaris 1.1.0 addresses these realities head-on by introducing key enhancements to its federation architecture.

The most notable addition is support for Hive Metastore (HMS) federation. This lets Polaris act as a unified control plane for environments where Hive-based tables still play a role, enabling a smoother migration path to Iceberg without requiring immediate rewrites or re-ingestion. For organizations looking to modernize incrementally, this unlocks flexibility while preserving continuity.

Equally important is the new modular federation framework. This architectural update makes it easier to support multiple catalog types—such as Hive, Glue, and Iceberg REST—within a single Polaris deployment. Rather than being tied to one metadata backend, Polaris now provides the extensibility needed to manage diverse environments, including hybrid and multi-cloud setups.

To make these capabilities more accessible, the Polaris CLI now includes commands for managing federated catalogs. This provides platform teams with fine-grained control over how different catalogs are integrated and surfaced, helping to standardize operations and reduce configuration overhead.

Together, these federation updates move Polaris closer to becoming the central metadata platform for any Iceberg deployment—regardless of where your data lives or how it’s cataloged.

Easier and More Secure Authentication for Modern Lakehouse Deployments

Security and simplicity rarely go hand in hand, but Polaris 1.1.0 takes a significant step toward making both achievable for enterprise teams. As Iceberg lakehouses scale across users, environments, and tools, authentication needs to be flexible enough to support a range of identity providers, yet seamless enough not to become a bottleneck for developers and admins.

This release introduces expanded support for external authentication systems, including native integration with Keycloak. That means organizations using OAuth2 or OIDC-based identity providers can now integrate directly with Polaris without requiring custom workarounds. Combined with new Helm chart configuration options, deploying Polaris with enterprise-grade auth is no longer a manual, error-prone process.

Another standout addition is the new IMPLICIT authentication type. Instead of requiring users to provide credentials each time they interact with Polaris explicitly, IMPLICIT mode allows credentials to be pulled automatically from environment variables or configuration files. This is especially valuable for scripting, automation, and working within secure containerized environments, where managing explicit credentials can be both tedious and risky.

These improvements make Polaris a stronger fit for production use cases that require secure multi-user access, single sign-on, and governed connectivity across teams. By giving admins more control over how users authenticate, while reducing friction for users themselves, Polaris 1.1.0 makes security a feature, not a roadblock.

More Control at Scale: Fine-Grained Features and Smarter Kubernetes Deployments

As Iceberg lakehouses mature, platform teams need more than just compatibility—they need control. Control over how features behave in production, how services scale during infrastructure changes, and how users interact with the system. Polaris 1.1.0 addresses this need with several new configuration options and Kubernetes-focused enhancements.

This release introduces a set of new feature flags that give teams more precise control over Polaris behavior. For example, the DEFAULT_LOCATION_OBJECT_STORAGE_PREFIX_ENABLED flag allows tables to be created with object storage-optimized paths by default, improving layout consistency and performance without requiring manual setup. The LIST_PAGINATION_ENABLED flag enables pagination in the REST catalog API, helping manage response sizes and improve performance at scale.

Governance and data hygiene also get attention. With the new PURGE_VIEW_METADATA_ON_DROP flag, admins can now configure whether Polaris should automatically clean up metadata files when views are dropped. This supports stricter cleanup policies and reduces orphaned metadata over time.

On the deployment side, the Polaris Helm chart has been enhanced with support for Pod Disruption Budgets (PDBs). This gives Kubernetes operators the ability to define how many Polaris pods must remain available during voluntary disruptions—such as node upgrades or rescheduling—improving overall cluster reliability and uptime. The chart also adds support for configuring external authentication and relational JDBC backend options, giving teams more flexibility in aligning Polaris with their existing infrastructure.

These additions reflect a broader theme in this release: production readiness. Whether you're deploying at scale, managing multi-tenant workloads, or optimizing for uptime, Polaris now offers more of the knobs and levers needed to support complex, enterprise-grade lakehouse environments.

Developer Experience Gets a Boost: Python Client and Bootstrap Enhancements

Building reliable data platforms isn't just about managing infrastructure—it's also about enabling developers to move quickly, test confidently, and automate repeatable workflows. Polaris 1.1.0 introduces significant enhancements to the developer experience, enabling teams to streamline integration, testing, and deployment.

One of the standout updates is the packaging of the Polaris Python client as a proper Python package. This makes installation and distribution significantly easier, especially in environments that rely on automation, scripting, or CI/CD pipelines. Developers can now install the client using standard Python tooling, integrate it into their workflows, and avoid the overhead of managing raw source distributions.

The Python client has also been enhanced with better error handling and a suite of integration tests. These changes improve reliability when using the client in automated systems and help catch issues earlier in the development process. Whether you're provisioning catalogs, scripting table creation, or managing metadata, the experience is now more stable and predictable.

Polaris also introduces new options to the bootstrap process, allowing users to specify custom schema files during database initialization. This is a practical enhancement for teams that want to preconfigure Polaris environments—especially in testing or self-managed deployments where automation is key. By defining the schema upfront, developers can reduce setup time and ensure consistency across environments.

These changes may not grab headlines, but they add up to a smoother, faster, and more reliable experience for anyone building on top of Polaris. They demonstrate that as Polaris expands its enterprise feature set, it’s also doubling down on usability and tooling, making it easier to adopt, automate, and trust in production.

Deprecations and Breaking Changes: What You Need to Know Before Upgrading

With any maturing open platform, evolution sometimes requires breaking changes—and Polaris 1.1.0 is no exception. While most of the updates in this release are additive and backward-compatible, there are a few changes that require attention from platform teams planning an upgrade.

The most immediate breaking change is in the Helm chart configuration. The default value for the authentication.tokenBroker.secret.symmetricKey.secretKey property has changed from symmetric.pem to symmetric.key. Teams using Helm to manage Polaris deployments should review this setting carefully, as mismatched secrets could prevent the authentication broker from initializing correctly. Updating this value as part of your upgrade process will ensure smooth deployment and secure token management.

Polaris 1.1.0 also introduces a change to how AWS-related storage configuration is handled. Specifically, the role-ARN property is no longer mandatory in S3 configurations. This simplifies integration with environments that use instance profiles or other credential mechanisms, but it may impact scripts or configurations that assume the presence of that field.

On the deprecation front, two key components are now marked for removal:

• The polaris.active-roles-provider.type property
• The ActiveRolesProvider interface

While these components are still functional in 1.1.0, future releases will remove them entirely. If you're currently relying on custom role management via this interface, it’s a good time to start planning a migration strategy. The introduction of external authentication and federation options in this release provides a natural path forward.

These changes are part of a broader effort to simplify Polaris’ configuration and improve security and interoperability. But like any upgrade, they require a careful read-through and validation. Before rolling out Polaris 1.1.0, it’s recommended to review your Helm values, verify compatibility with your authentication setup, and begin transitioning away from deprecated properties. Doing so will ensure your deployment is aligned with the latest architecture and ready for future enhancements.

Conclusion – Polaris 1.1.0 Strengthens the Foundation for the Open Lakehouse

As Apache Iceberg adoption accelerates across enterprises, the need for a robust, open, and extensible catalog becomes more critical. Polaris 1.1.0 meets that need by delivering meaningful upgrades across federation, authentication, developer tooling, and deployment flexibility—while maintaining a clear focus on interoperability and simplicity.

Support for Hive Metastore federation and modular catalog integration makes Polaris more adaptable to real-world data environments. Enhancements to external authentication and Helm-based deployment reduce friction for teams operating in secure, regulated environments. And with expanded support for S3-compatible storage, the catalog can now accompany your lakehouse architecture into hybrid and edge deployments without compromise.

Built by the co-creators of Apache Polaris, Dremio and Snowflake, along with a growing community of contributors across the industry. This release demonstrates the project’s ongoing commitment to openness, performance, and ease of use. Whether you're building your first Iceberg catalog or scaling across multiple regions and clouds, Polaris 1.1.0 provides the flexibility and control to do so confidently.

To get started with the new features, check out the latest documentation or spin up a local Polaris environment with MinIO using the Quick Start Guide. The Polaris community continues to grow, and this release lays the groundwork for more collaboration and innovation ahead.

If you’re building a lakehouse on Iceberg, Polaris 1.1.0 is ready to meet you there.

Download a Free Copy of "Apache Polaris: The Definitive Guide"