Cross-posted. This article's canonical home is iceberglakehouse.com.

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

By Alex Merced, Head of Developer Relations at Dremio

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, and 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. And 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, because the current dev list traffic shows where the community's ambition points next, and the past two months have been remarkably busy.

The discussion that would have surprised me a year ago is semantic layer support in Apache Polaris, one of the highest-traffic threads of the season, running alongside a formal vote that passed to accept an open semantic model API specification into the project's orbit. The reasoning: a catalog already knows every table, every schema, and every permission. Metrics definitions, business entities, and model semantics are metadata of the same kind, and the rise of AI agents querying lakehouses directly has made a machine-readable semantic layer urgent rather than nice-to-have. An agent that knows only tables and columns guesses at business meaning. An agent that can ask the catalog what "active customer" means stops guessing. The community deciding that this belongs near the catalog, governed like everything else, is a genuinely important scope expansion, and it echoes the Table Sources direction discussed earlier in the year of extending Polaris toward a universal registry for tables, views, functions, metrics, and models.

Lineage is moving too, through a sustained OpenLineage proposal thread exploring how Polaris should emit and integrate lineage information, which pairs naturally with the proposal for REST endpoints exposing table metrics and events and a companion thread on forwarding Iceberg scan and commit metrics through the event system. Assemble those pieces and you can see the shape being built: the catalog as the observability plane of the lakehouse, knowing not just what exists but what happened, who touched it, and where it flows. There is even a thread on mechanisms to purge the events and metrics tables, which tells you people are running this at enough volume to worry about retention.

The protocol-level work continues alongside. An idempotency-key design discussion for the Iceberg REST API has been converging on a preferred model, addressing the retry-safety problems that any high-commit-rate deployment eventually meets. A thread on status codes for rename conflicts sounds trivial and is exactly the kind of precision that makes a spec implementable twice. Iceberg table encryption support has its own active design discussion. And a long thread on non-IRC endpoints appearing in IRC config responses, the single busiest subject of the past two months, is the community carefully negotiating how Polaris-specific capabilities should surface without polluting the standard Iceberg REST surface, which is precisely the discipline that keeps an implementation from drifting into a dialect.

Two more threads round out the picture of a project growing into its user base. A discussion on whether the Polaris web console should live in the main repository signals that the human interface, long the gap between Polaris and the commercial catalogs, is becoming a first-class concern. And a scale question from the field, asking about the feasibility of one realm per tenant at ten thousand tenants, tells you who is showing up: platform builders embedding Polaris inside multi-tenant products. When your issue tracker fills with questions about the tenth thousand tenant rather than the first table, the adoption story is telling itself.

Adoption: Engines, Vendors, and the Competitive Field

So who actually uses this thing? The picture in July 2026 has three rings.

The inner ring is engine support, which is now broad enough to stop listing apologetically. Polaris's REST implementation is exercised by Apache Spark, Apache Flink, Trino, Apache Doris, StarRocks, Dremio, and the growing family of Iceberg clients in Python, Rust, and Go, since anything that speaks the Iceberg REST protocol speaks Polaris. This was always the design bet: implement the standard faithfully and inherit the ecosystem, rather than courting integrations one by one.

The middle ring is managed offerings. Snowflake Open Catalog delivers Polaris as a managed service with Snowflake's Horizon governance integrated around it, and Snowflake's own engine reads and writes Iceberg through it. Dremio ships Polaris at the core of its catalog experience, wrapped with query federation and semantic layer capabilities, provisioned by default in Dremio Cloud. The pattern to appreciate: both co-creators sell managed Polaris and compete on what surrounds it, which keeps both invested in the core while keeping the core neutral. Meanwhile self-managed deployment has gotten honestly easier, with the single binary, Helm chart, and a widening set of persistence backends, though running any highly available JVM service with a database remains real operational work, and teams should budget for it.

The outer ring is the competitive field, and it deserves a sober paragraph rather than a victory lap. Unity Catalog remains the center of gravity for Databricks-first shops and has genuine strengths in AI asset governance and business semantics that Polaris is only now moving toward, exactly the gap the semantic layer work addresses. Apache Gravitino, a TLP since mid-2025, pursues the federated metadata lake vision with an AI model catalog and agent-facing features, overlapping Polaris most directly on the catalog-of-catalogs story. Lakekeeper offers a lean Rust-native REST catalog for teams that want minimal footprint. Nessie continues to serve the git-for-data niche, and the cloud-native catalogs, Glue, BigLake Metastore, OneLake, keep improving their REST faces. The stabilizing truth across all of it is that the REST protocol is the meeting point: because engines configure against the protocol, catalog choices have become reversible in a way they never were in the Hive era, and federation makes coexistence a strategy rather than a compromise. Polaris's differentiated claim in that field is the one it was founded on: the most standards-faithful, vendor-neutral implementation, governed where no roadmap can be unilaterally captured.

What I Would Do: Guidance for Teams in 2026

Let me translate the state of things into decisions, the way I would advise a platform team this quarter.

If you are standing up a new Iceberg lakehouse, Polaris is the default I would start from, either self-managed if you have the operational muscle or through a managed offering if you do not. You get the standard protocol, credential vending, RBAC, and a federation path for everything you cannot migrate, and the TLP governance de-risks the decade-long horizon. Configure engines against the REST protocol and you preserve the option to change your mind, which is worth more than any feature comparison.

If you are living with Glue, Hive, or a warehouse-native catalog today, you no longer face a migration decision. Register what you have as federated sources, put Polaris in front as the governance and discovery plane, and migrate tables opportunistically or never. Run the numbers on the operational side honestly: a federated Polaris is one more service on your critical path, so it should earn its place through consolidation of access control, not architectural fashion.

If you are betting on AI agents against your lakehouse, and increasingly everyone is, watch the semantic layer and events work closely and design toward it. Agents need three things from a catalog: discovery of what exists, enforcement of what they may touch, and semantics for what things mean. Polaris ships the first two today and is building the third in the open. Structuring your metadata, descriptions, and access model now, with that trajectory in mind, is cheap insurance.

And wherever you land, hold every catalog, Polaris included, to the same tests I apply throughout this article: does it implement the standard without dialect drift, can another vendor's engine read and write through it without permission or plugins, and can you leave it without rewriting your platform. Catalogs are the control point of the lakehouse. The entire point of the open movement is that control points should be things you choose, continuously, rather than things that choose you.

Credential Vending, Explained Properly

Since credential vending shows up in nearly every Polaris conversation and most explanations of it stay at the bullet-point level, let me give it the accessible treatment, because it is the single feature that most changes the security posture of a lakehouse.

Start with the problem. In a lakehouse, data lives in object storage and compute lives everywhere else: Spark clusters, Flink jobs, BI tools, notebooks, and now AI agents. Traditionally, every one of those compute environments needed storage credentials, an IAM key or service account with rights to the buckets. Multiply that across teams, tools, and environments and you get credential sprawl: long-lived secrets sitting in cluster configs, notebook environments, and CI pipelines, each one a breach waiting for a leak, each one scoped more broadly than any single job needs because narrow scoping across that many holders is unmanageable. Security teams hate this picture for good reason, and it has quietly blocked more lakehouse projects than any performance concern ever did.

Credential vending inverts the model. Engines hold no storage credentials at all. They hold one thing: an identity with Polaris. When an engine wants to read or write a table, it asks Polaris, Polaris checks the RBAC grants for that principal against that table, and only then does Polaris turn to the cloud provider and mint a short-lived, narrowly scoped token, rights to exactly the storage paths that table occupies, expiring in minutes or hours. The engine receives the token, does its work, and the token dies on schedule. Nothing long-lived ever leaves the vault.

The analogy I use on stage: the old model is giving every hotel guest a master key because managing hundreds of room keys is annoying. Vending is the front desk checking your reservation and cutting a key card that opens your room only, and expires at checkout. Nobody audits master keys. Everybody can audit key cards.

The 2026 releases show what happens after the concept works and the auditors arrive. Session tags flowing into CloudTrail mean every vended credential can be correlated to the principal and operation that requested it, so storage access logs finally answer "who" rather than "which shared key." Storage-scoped credentials and the unified payload format tighten exactly what each token can touch and keep distributed executors consistent mid-query. KMS support extends the model to encrypted buckets. And the dev list thread on a GCP counterpart to the AWS session tags work shows the same treatment spreading across clouds. This is what I mean when I say Polaris crossed from capability to operability this year: vending existed in 2024, and in 2026 it satisfies an audit.

One more implication worth spelling out, because it connects to where the ecosystem is going. Credential vending is the mechanism that makes multi-engine governance real rather than rhetorical. Access rules enforced only inside one engine evaporate the moment a different engine touches the same files. Rules enforced at the catalog through vending bind every engine equally, including engines that did not exist when the rules were written, including the AI agents now arriving. The catalog can be the policy point precisely because it is the credential point.

A Worked Example: One Company, Three Stages of Adoption

Abstract capability lists never convince anyone, so let me run a composite scenario drawn from the adoption patterns I actually see, one fictional company moving through three honest stages.

The company: a retailer with a data estate that grew by accretion. Core analytics tables live in Iceberg on S3, cataloged in AWS Glue because that was the default. A legacy Hive Metastore governs an older Hadoop-era warehouse that finance still queries. One acquired business unit runs on GCP with tables in BigQuery Metastore. Spark handles ETL, Dremio serves BI, a growing crew of data scientists uses Python and DuckDB, and this year the CTO wants agents answering questions against governed data.

Stage one: govern without moving anything. The platform team deploys Polaris, either self-managed on Kubernetes via the Helm chart with PostgreSQL behind it, or through a managed offering. They do not migrate a single table. Glue, the Hive Metastore, and BigQuery Metastore register as federated catalogs, and Polaris projects all three through one set of Iceberg REST endpoints. Engines repoint their catalog configuration at Polaris, a config change, not a code change, precisely because everything speaks the REST protocol. The immediate win is a single discovery plane: for the first time, one namespace answers "what tables exist," spanning three clouds' worth of history. The second win lands with security: principals and roles get defined once, and credential vending replaces the zoo of IAM keys living in Spark configs. Nothing about the data moved. The governance moved.

Stage two: consolidate where it pays. With federation carrying the legacy, the team makes migration a business-case decision instead of a prerequisite. New tables get created directly in Polaris-managed internal catalogs. The highest-value Glue tables migrate with the catalog migrator tooling when their pipelines get touched anyway. The Hive Metastore is left to age in place behind federation, queried but frozen, on a path to eventual retirement that no longer blocks anything. Meanwhile the operational muscles build: metrics reporting flows from engines back into Polaris, so the team can finally see which tables are hot, which are dead, and which governance rules actually get exercised. Policies for retention and maintenance land in the policy store. OPA arrives when the security team wants access rules expressed as reviewable policy code alongside the rest of their infrastructure policies.

Stage three: the agent era. The CTO's agents arrive, and the earlier stages turn out to have been the preparation. Each agent gets a principal with narrow role grants, exactly like a human analyst, and vending ensures an agent can never touch storage beyond its grants, no matter how creatively it composes queries. Discovery endpoints give agents the map of what exists. And as the semantic layer work lands in Polaris, the definitions the BI team curated, what counts as an active customer, how margin is computed, become machine-readable context the agents consume from the same governed catalog, rather than folklore embedded in prompts. The audit story that took stage one and two to build now covers human and machine access identically, which is the only version of agent governance that survives contact with a compliance review.

Three stages, no big-bang migration, each stage justified by its own returns. That is the adoption shape federation made possible, and it is why I keep saying the 2026 Polaris story is less about features than about the removal of reasons to wait.

How to Follow and Join the Project

A short practical section, because "get involved" advice usually stays too vague to act on, and Polaris is at the stage where new participants shape real outcomes.

For following along, the dev mailing list is the source of record, archived and searchable at lists.apache.org, and its traffic is manageable, a few hundred messages in a busy month across perhaps thirty active subjects. Skim subjects weekly and open anything tagged DISCUSS, PROPOSAL, or VOTE that touches your concerns. The GitHub discussions carry the roadmap and the longer design documents, the community syncs on topics like authorization are announced on the list with notes posted back, and the project publishes its board reports publicly now that it reports directly to the ASF board. An hour a month keeps you genuinely current, and my weekly Apache newsletter exists for people who would rather have that hour done for them.

For contributing, the honest advice is to start where the project's growth is creating gaps. Federation extensions want more sources, and the BigQuery module arriving from a community contributor is the template: a well-scoped extension with tests, developed in the open. The console, documentation, Helm chart refinements, and the testing infrastructure threads all welcome hands that are not ready to touch the authorization core. Client-side work in the Iceberg language ecosystems, Python, Rust, Go, exercises Polaris constantly and surfaces protocol issues worth reporting. And if your organization runs Polaris at any interesting scale, writing up what you hit, the way the ten-thousand-tenant question arrived on the list, is a contribution the project visibly values, because production truth is the scarcest input any young project has.

The committer announcements this year all followed the same path: sustained, visible, useful participation. There is no other door, which is rather the point of the Apache way.

Questions I Hear Most Often

The recurring questions from meetups, the podcast, and customer conversations, answered directly.

Is Polaris just a Snowflake project wearing an Apache jacket? The graduation process exists to answer exactly this, and the observable evidence says no. The PMC and committer base span competing vendors and independents, contribution flow comes from well beyond the two founders, with the BigQuery federation work arriving from the community being a nice concrete example, and decisions happen on a public list where anyone can watch vetoes and votes. Snowflake and Dremio remain the largest investors of engineering time, which is normal for young ASF projects, and the trajectory of committer announcements points the right direction. Judge it by the archives, which are public, rather than by anyone's assurances, including mine.

Polaris or Unity Catalog? The honest answer is that this is mostly a question about your center of gravity. Deep Databricks estates get real value from Unity's integration and its maturity on AI asset governance. Multi-engine, multi-vendor estates get real value from Polaris's neutrality and standards fidelity. The two increasingly meet at the Iceberg REST boundary, and federation features on both sides make coexistence practical. What I push teams to reject is the framing that this choice is permanent: configure against the protocol, keep your governance rules exportable, and the decision stays revisable.

Can Polaris handle non-Iceberg tables well enough to be my only catalog? Generic tables are generally available and genuinely useful for cataloging Delta and Hudi assets in one namespace, with discovery and access control unified. Be precise about what that does and does not mean: Polaris governs the entry point, but format-specific capabilities still depend on the engines reading those tables, and write-path parity across formats remains an evolving story, with directions like Delta write support and file-based tables living on the roadmap rather than in releases. For a mixed estate mid-migration, it is already the right tool. For a permanently multi-format strategy, watch the generic table and directories threads closely.

What is the operational footprint really like? A Quarkus JVM service, a relational persistence backend with PostgreSQL the common choice and CockroachDB now supported, and the usual high-availability engineering around both. The Helm chart makes Kubernetes deployment straightforward, and the diagnostics and testing threads on the dev list show operability getting steady attention. It is not heavy by data infrastructure standards, and it is not free. The managed offerings exist precisely for teams that want the protocol without the pager.

Does Polaris support the newest Iceberg features like v3 tables? Polaris tracks the Iceberg REST specification, and its job is to broker metadata rather than interpret every table feature, so support for format-version capabilities mostly rides on the Iceberg libraries and the engines. The catalog-relevant edges, like the idempotency work, metrics reporting, and the encryption discussion, are active on the dev list. In practice, teams are running v3 tables through Polaris with current engines today, and the catalog has not been the bottleneck in that story.

What should I watch for the rest of 2026? Four things. The semantic layer implementation following the accepted specification, because it defines whether Polaris closes the AI-governance gap. The authorization work maturing toward fine-grained policies, because that is the enterprise checklist item most often asked about. The events and lineage endpoints hardening, because the observability plane is the next competitive front. And the release notes of whatever ships after 1.6 on the now-reliable cadence, because in this project, the release notes have become the roadmap made visible.

Closing Thoughts

Two years ago, Polaris was an announcement and an argument: that the catalog layer, like the table format before it, was too important to belong to anyone. One year ago it was an incubating project with a 1.0 and a lot of experimental flags. In July 2026 it is a Top-Level Project on a monthly release train, with federation and credential vending in production, governance layering up from RBAC through policy engines toward portability, and a community whose current debates, semantics, lineage, agents, tenancy at the ten-thousand scale, are the debates of a project whose fundamentals are settled.

The catalog wars framing is fading, and what replaces it is quieter and better: a protocol everyone implements, a neutral reference implementation anyone can run, and competition moving to the layers above. That is how Iceberg won, and it is the path Polaris is walking a few years behind, co-created by two competitors precisely so that it could belong to neither.

If you want to go deeper than an article can take you, that is what the book is for. I co-authored Apache Polaris: The Definitive Guide and Apache Iceberg: The Definitive Guide for O'Reilly, and I have written further titles on lakehouse architecture, data engineering, and agentic analytics, all built to turn these systems from vocabulary into working knowledge.

Browse the full collection of my books on data and AI at books.alexmerced.com.