The State of Apache Polaris in July 2026: From Incubating Catalog to the Governance Layer of the Open Lakehouse

The State of Apache Polaris in July 2026: From Incubating Catalog to the Governance Layer of the Open Lakehouse

I have a personal stake in this one, so let me declare it up front. Apache Polaris was co-created by Snowflake and Dremio, I work at Dremio, and I co-authored Apache Polaris: The Definitive Guide for O'Reilly. I have watched this project from the first commit, through donation to the Apache Software Foundation in August 2024, through eighteen months of incubation, and past its graduation to a Top-Level Project in February 2026. I am not a neutral observer. What I can promise instead is accuracy, receipts from the dev list, and honesty about what is finished versus what is still forming.

The short version of where Polaris stands in July 2026: the project graduated, the release train runs monthly, federation and governance have gone from roadmap slides to shipped extensions, and the community's current arguments are about semantic layers, lineage, and serving AI agents, which tells you the foundation underneath is no longer in question. The catalog conversation that dominated 2025 - which implementation should you trust - has largely resolved into a different and better question: how much of your lakehouse should the catalog govern?

This article walks through all of it. What Polaris is and why the catalog layer became the architecture decision of this era. What has shipped release by release. What the dev list is debating right now, in July, and why those debates matter. Where adoption actually stands across engines and vendors. And what I would do if I were choosing a catalog this quarter. As always, my goal is that the logic clicks, so that every future Polaris announcement makes sense to you on arrival.

Why the Catalog Became the Decision That Matters

A quick foundation for anyone arriving fresh, because the stakes only make sense with the architecture in view. An Apache Iceberg table is files plus metadata, and something has to hold the authoritative pointer that says which metadata file is current. That something is the catalog. Every commit routes through it. Every engine finds tables through it. It is a small service with an outsized position: whoever controls the catalog controls access, and whoever controls access controls governance.

For years this layer was an afterthought - a Hive Metastore inherited from another era or a cloud service adopted by default. Two things changed that. First, the Iceberg REST Catalog specification turned the catalog into a protocol rather than a library, meaning any engine speaking HTTP could work with any compliant catalog, which made the catalog choice consequential and portable at the same time. Second, the format war ended. With Iceberg established as the shared substrate across Snowflake, Databricks, AWS, Google, Microsoft, and the open source engines, the table format stopped differentiating anyone. Competition moved up a layer, to the catalog, and 2025 became the year of what many called the catalog wars.

Polaris exists as the open answer to that fight. The argument for it mirrors the argument for Iceberg itself a few years earlier: commercial catalogs serve their creators' ecosystems well, but the ecosystem needs a catalog primitive that no single vendor controls, governed at a neutral foundation, extensible by anyone. Snowflake and Dremio co-created it, donated it to the ASF in August 2024, and an incubation community that grew to include contributors from Google, Microsoft, Confluent, AWS, and dozens of other organizations carried it to graduation.

Polaris implements the Iceberg REST specification and layers on the things a production catalog needs that the spec does not define: multi-catalog management, role-based access control, credential vending, federation, and a policy store. That is the setup. Now the state of play.

Graduation, and Why It Mattered More Than a Badge

In February 2026, Apache Polaris graduated from the Apache Incubator to become a Top-Level Project. It is worth pausing on what that actually certifies, because the ceremony obscures the substance. Incubation at the ASF is not a waiting room. It is an audit. A project must demonstrate that its community is diverse enough to survive any single vendor walking away, that its governance follows the Apache way of open decision-making on public lists, that its releases meet legal and procedural standards, and that committership grows on merit. Projects fail incubation regularly.

Polaris passed in eighteen months, which for a project born from two competing vendors is fast, and the diversity requirement is the one I would highlight. The committer and PMC rolls now span cloud providers, engine vendors, governance vendors, and independents, and the new-committer announcements have kept arriving through the spring, with names like Christopher Lambert and Nandor Kollar welcomed in recent months.

Graduation also changed the project's posture in ways you can observe. The first post-graduation board report went out in March under the coordination of Jean-Baptiste Onofré, the release cadence tightened, and the dev list picked up the kind of process threads that signal a project settling in for the long haul: merge-button policies, code organization for supporting multiple Spark lines, dependency modernization threads on Jackson 3 and Quarkus 4 readiness, and a debate over the future of the regression test infrastructure. None of that is glamorous. All of it is what a ten-year project looks like in year two.

For adopters, the practical meaning is risk reduction. A TLP with a diverse PMC cannot be strategically strangled or quietly abandoned by any one company, including the two that created it. That property, more than any feature, is what enterprises were waiting to see before betting governance infrastructure on the project.

The Release Train: 1.0 Through 1.6 in One Year

The clearest way to see Polaris maturing is to walk the releases, because the arc from mid-2025 to mid-2026 tells a coherent story.

Version 1.0 arrived in the summer of 2025 as the first production-ready release: a single downloadable binary, a published Helm chart for Kubernetes, support for external identity providers like Okta and Google alongside the built-in identity system, and the first version of the policy store - a persistent home for policies like compaction and snapshot expiration with REST endpoints for managing their lifecycles. It also planted three seeds explicitly labeled experimental:

• Generic tables for non-Iceberg formats
• An event listener framework
• Catalog federation

Hold those three in mind, because the next year of releases is largely the story of those seeds growing up.

Version 1.3.0 shipped in January 2026 and matured two of them. Generic tables went generally available, letting Polaris reliably catalog Delta Lake and Hudi tables alongside Iceberg in the same namespaces - a meaningful step for every organization mid-transition between formats. Observability arrived through native Iceberg metrics reporting: engines can now push query-level execution metrics - rows scanned, bytes read, commit activity - back to the catalog through the Iceberg REST API, turning Polaris from a passive metadata store into a source of operational signal about how tables actually get used. And the release introduced integration with Open Policy Agent, the first step toward externalized, auditable authorization beyond static role grants.

Version 1.4.0, in April, was the first release after graduation, and it read like a hardening release for regulated environments. Credential vending - the mechanism by which Polaris hands engines short-lived, scoped storage tokens instead of letting credentials sprawl across client machines - gained AWS STS session tags so storage access can be correlated in CloudTrail audits, plus storage-scoped credentials and S3 KMS encryption support. CockroachDB joined the persistence backend options. Metrics gained database persistence. And federation, the third seed from 1.0, reached Hive Metastore, AWS Glue, and external Iceberg REST catalogs.

Version 1.5.0, in May, pushed federation further with Google BigQuery Metastore support contributed through the community, meaning a single Polaris instance can now project tables living in GCP's metastore as standard Iceberg REST endpoints next to everything else it manages. The credential vending payload was restructured into a unified format with consistent expiration semantics - the kind of unglamorous refinement that matters enormously when distributed query executors need consistent session keys mid-job.

Version 1.6.0 landed on schedule at the end of June, keeping the monthly-to-six-weeks cadence the project has now sustained for a year.

Step back from the individual items and the arc is unmistakable. The 2025 question was "does it work." The 2026 releases answer operator questions: can I audit it, can I encrypt it, can I run it on my database, can I point it at the catalogs I already have. That progression, from capability to operability, is what production adoption actually requires, and the release notes show the project's center of gravity has moved there.

Federation: The Catalog of Catalogs Became Real

Of everything that shipped this year, federation deserves the deepest look, because it changed what kind of thing Polaris is. The original pitch for any catalog is centralization: put your tables in me. The problem with that pitch is that no real enterprise starts from zero. Tables already live in Glue because the AWS account predates the lakehouse strategy. Tables live in a Hive Metastore because the Hadoop era happened. Tables live in BigQuery Metastore because one division runs on GCP. A catalog that demands migration before it delivers governance has priced itself out of most organizations.

Federation inverts the pitch. Polaris registers external catalogs - Hive, Hadoop, Glue, BigQuery Metastore, other Iceberg REST catalogs - as federated sources and projects their contents through its own endpoints, governed by its own access model. The repository now carries dedicated extension modules for Hive, Hadoop, and BigQuery federation, and the dev list through the spring has been working the practical edges: how credentials pass through to federated sources, including an active question on STS token passthrough for federated catalogs, and how multiple data sources can be configured with runtime activation - one of the busier threads of the past two months.

The strategic meaning is that Polaris stopped competing with your existing catalogs and started offering to govern them. You adopt it as a layer, not a destination. Migration becomes optional and gradual rather than a prerequisite, with the separate catalog migrator tooling available when consolidation does make sense. In my conversations with platform teams, this reframing has done more for Polaris adoption than any single feature, because it converts a rip-and-replace proposal into an additive one. It is also the architecture that multi-cloud reality demands: nobody's tables live in one place, so governance has to be the thing that spans places.

Dremio's own product architecture reflects the same philosophy, for what it is worth: the Dremio Open Catalog is Polaris at the core with federated sources around it, presenting one governed namespace across Iceberg tables, databases, warehouses, and external catalogs. Snowflake's Open Catalog offers Polaris as a managed service from the other co-creator's side. Both companies betting their catalog products on the same open core is exactly the outcome the donation was designed to produce.

Governance: From RBAC to Policy Engines to Portable Policy

The second major thread of the year is governance depth, and it layers up nicely.

The base layer, shipped and stable, is Polaris's native model: principals, principal roles, and catalog roles, with grants at catalog, namespace, and table level, enforced identically no matter which engine comes through the REST API. Add credential vending and you get the property that makes security teams exhale: engines never hold long-lived storage credentials at all - they receive short-lived scoped tokens per operation, now with the audit correlation and encryption support from 1.4.

The middle layer, maturing fast, is externalized authorization. The OPA integration that arrived in 1.3 lets authorization decisions route to an external policy engine, so access rules can be expressed as policy code, versioned, tested, and aligned with the policy systems an organization already runs elsewhere. A Ranger extension sits alongside it in the repository for shops standardized on that ecosystem, and the community has been running dedicated syncs on Polaris authorization to work the design forward, with fine-grained access control - row and column level - as the destination the roadmap has pointed at all along.

The top layer, and the one to watch skeptically and hopefully at once, is policy portability across systems. In April 2026, Snowflake publicly committed to governance portability through Polaris - the idea that access policies authored in one system could be enforced by another, with Polaris as the exchange point. I flagged then, and maintain now, that the announcement was directional: as of this writing, the policy exchange mechanics are still more proposal than shipped engineering, and governance federation remains in preview territory rather than general availability. But the direction is the right one, and it is the same direction the open format movement has always pointed: the policies about your data should be as portable as the data itself. If that vision lands, it lands through a neutral catalog, which is precisely the position Polaris was built to occupy.

My honest scorecard on governance: the base layer is production-proven, the policy engine layer is real and deployable with engineering effort, and the portability layer is a promise with credible momentum. Plan accordingly.

The July Dev List: Semantic Layers, Lineage, and the Next Perimeter

Now the freshest material, b