What is the difference between Apache Polaris and Nessie?

Both are open-source Iceberg catalogs, but they optimize for different things. Polaris is built around the Iceberg REST specification, centralized role-based access control, and credential vending, aimed at broad multi-engine interoperability. Nessie adds a Git-like model over the catalog: branches, tags, commits, and multi-table transactions, so you can isolate and roll back changes across many tables at once.

Did Apache Polaris and Nessie merge?

No. The merge was announced in 2024, with the stated intention that Nessie's capabilities would be contributed to Polaris and Nessie eventually retired. As of mid-2026 it has not happened. Polaris graduated from incubation and ships on a regular release train; Nessie continues independently serving the git-for-data niche. A lot of comparison content still repeats the 2024 plan as though it were current.

Which Iceberg catalog should I choose, Polaris or Nessie?

Default to Polaris. It is the neutral, spec-faithful REST catalog with the broader engine ecosystem and the more conventional governance model, and it now has ASF graduation behind it. Choose Nessie when you specifically want catalog-level branching — testing a pipeline against a branch of production data, or committing changes across several tables atomically. That capability is genuinely distinctive and most teams do not need it.

Is Apache Polaris the same as Snowflake Open Catalog?

Snowflake Open Catalog is Snowflake's managed service built on Polaris; Apache Polaris is the open-source project it came from and which Snowflake donated to the ASF. Running Open Catalog means running Polaris without operating it yourself. Snowflake Horizon, often listed alongside these, is the governance suite rather than the catalog.

Apache Polaris vs Nessie: The Merger That Never Happened

Start with the thing most comparisons of these two get wrong. In 2024 it was announced that Polaris and Nessie would merge, with Nessie’s capabilities folded into Polaris and Nessie eventually retired. It did not happen. As of mid-2026 both projects are alive and separate: Polaris graduated from incubation and ships on a regular release train, while Nessie continues to serve the git-for-data niche it invented.

That matters practically, because a fair amount of the guidance you’ll find is still written against the 2024 plan — advising people to pick Polaris on the grounds that Nessie is going away. Nessie isn’t going away. Choose on what each actually does.

The short version: default to Polaris. Choose Nessie only if you want Git-like branching of the catalog itself, which is a real capability that most estates don’t need.

Polaris vs Nessie, side by side

	Apache Polaris	Nessie
Origin	Donated by Snowflake, now ASF	Dremio-backed, open source
Status, mid-2026	Graduated, monthly release train	Independent, active
Core idea	Spec-faithful REST catalog + RBAC	Git semantics over the catalog
Access control	Granular table and namespace privileges	Branch- and commit-oriented
Credential vending	Yes	Limited
Multi-table transactions	No	Yes — that is the point
Branch / tag / rollback	No	Yes
Engine ecosystem	Broad: Spark, Flink, Trino, Doris, DuckDB, Presto, Starburst	Narrower, Dremio-centred
Managed option	Snowflake Open Catalog	Dremio
Choose it when	You want a neutral default	You want data as branchable state
Fails by	Being unremarkable, which is the goal	Solving a problem you don’t have

What Nessie actually gives you

Nessie’s distinctive claim is not access control or interop. It’s that the catalog behaves like Git: you can branch it, commit to the branch, test against it, and merge or discard. Because the branch covers the whole catalog rather than one table, you get something genuinely hard to obtain otherwise — atomic changes across several tables at once.

The workflow that justifies it looks like this:

-- Branch the entire catalog, not one table
CREATE BRANCH etl_run_2026_08_08 IN nessie FROM main;
USE REFERENCE etl_run_2026_08_08 IN nessie;

-- Rewrite several related tables; nothing is visible on main yet
MERGE INTO sales.orders   ...;
MERGE INTO sales.line_item ...;
MERGE INTO sales.customer  ...;

-- Validate the branch, then publish all three tables atomically
MERGE BRANCH etl_run_2026_08_08 INTO main IN nessie;

Anyone who has shipped a pipeline that half-updated three tables and left the warehouse internally inconsistent for forty minutes can see the appeal. It is the same instinct as idempotent pipelines, pushed up to the catalog: make the unsafe window not exist rather than making it short.

What Polaris actually gives you

Polaris is deliberately less interesting, and that is its argument. It implements the Iceberg REST catalog specification faithfully, vends credentials so the catalog can act as the real security boundary, and applies conventional role-based privileges at table and namespace level. Every spec-faithful engine talks to it without special handling.

Its second argument is governance of the project rather than of the data. It sits with the Apache Software Foundation with contributions from multiple vendors, it has graduated, and it has a predictable release cadence. If your reason for avoiding Unity Catalog and Glue is that you don’t want a single vendor holding the component you cannot casually swap, Polaris is the answer that reasoning points to. Snowflake’s managed Open Catalog is the same codebase operated for you.

One line versus branchable state. And a merger announcement that guidance still repeats two years on.

Why the merger stalled, and why you shouldn’t plan around it resuming

The two projects were never as complementary as the announcement implied. Polaris is organised around a single authoritative pointer per table with privileges layered on top — the model the Iceberg REST spec assumes. Nessie is organised around versioned references, where “current” is a property of the branch you’re reading. Merging them is not a matter of porting features; it means choosing which of two models of catalog state is the real one.

Practical implication: do not choose either catalog on the assumption they will converge. If branching is what you need, run Nessie and accept a narrower engine ecosystem. If it isn’t, run Polaris and don’t pay for a capability you won’t use.

The decision rule

Do you need atomic changes across MULTIPLE tables,
or branch-and-test against a copy of production catalog state?
   → Nessie. Nothing else does this cleanly.

Do you want a neutral, spec-faithful catalog with broad engine support
and conventional RBAC?
   → Polaris. Managed: Snowflake Open Catalog.

Not sure, and no multi-table transaction has ever hurt you?
   → Polaris. The branching model has real operational cost,
     and inventing a use for it after the fact is how estates
     accumulate machinery nobody maintains.

And the honest framing that applies to every catalog decision: the data files never move, so this feels like a reversible choice. It isn’t. Every engine config, every access policy, and all accumulated audit history live in the catalog, which is exactly why it deserves the evaluation weeks the format choice no longer needs.