Summary

What it is

An open-source REST catalog for Apache Iceberg with centralized RBAC, originally developed by Snowflake and donated to Apache.

Where it fits

Polaris is the vendor-neutral answer to the "catalog wars" of 2025-2026. As Iceberg becomes the dominant table format, every engine needs a single source of truth for table metadata. Polaris implements the Iceberg REST Catalog Spec, making it the interoperable choice for multi-engine lakehouse environments.

Misconceptions / Traps

Polaris is a metadata catalog, not a query engine. It does not execute queries — it serves metadata to engines that do.
Requires a persistence backend (PostgreSQL or similar). Not a standalone binary; deployment complexity is non-trivial.

Key Connections

implements Iceberg REST Catalog Spec — the standard REST interface for Iceberg catalogs
enables Apache Iceberg — provides metadata management for Iceberg tables on S3
solves Vendor Lock-In — engine-neutral catalog alternative to AWS Glue or Databricks Unity
competes_with Unity Catalog, Apache Gravitino

Definition

What it is

An open-source REST catalog for Apache Iceberg, originally developed by Snowflake and donated to the Apache Software Foundation. Provides centralized role-based access control (RBAC) for Iceberg table metadata.

Why it exists

As multiple compute engines (Spark, Trino, Flink, Snowflake) read and write to the same Iceberg tables on S3, organizations need a single, vendor-neutral catalog that enforces consistent access policies. Polaris decouples metadata governance from any specific engine.

Primary use cases

Centralized Iceberg catalog for multi-engine environments, RBAC enforcement across data lakehouse platforms, vendor-neutral metadata management.

Recent developments

Latest signals

Latest release: v1.5.0 (current as of June 2026). Tracking the upstream stable release line. Per apache/polaris releases.
Apache Polaris's first serious security reckoning: a four-CVE credential-vending cluster disclosed May 4, 2026, all fixed in 1.4.1. The lead flaw, CVE-2026-42810 (CVSS 4.0 9.4 / CVSS 3.1 9.9), is an S3 IAM policy bypass via wildcard table names: an attacker holding only namespace-scoped TABLE_CREATE + TABLE_WRITE_DATA on * creates a table whose name contains literal wildcard characters (e.g. f*.t1, *.*), which Polaris passes unescaped into the generated S3 resource patterns and s3:prefix conditions, so the vended temporary credentials match other tables' object paths — enabling unauthorized list/read/create/delete of any table's S3 objects and Iceberg metadata with no direct Polaris permission on the victim table. Per CVE-2026-42810 (ThreatInt).
The root cause is the credential-vending path itself, not a single bug — three sibling CVEs share it. CVE-2026-42809 (9.4/9.9) vends over-broad temporary credentials during staged table creation, before the effective table location is validated or durably reserved, letting a low-privileged attacker steer credential scope via attacker-supplied write.data.path/write.metadata.path; CVE-2026-42812 (9.4/9.9) lets a user with table-alter rights set write.metadata.path to bypass the commit-time storage-location revalidation and force metadata writes (and credential vending) to an attacker-chosen location; CVE-2026-42811 (9.4/9.9) is the GCS analogue of 42810 — unescaped namespace/table identifiers (with CEL fragments and a single quote) collapse the Credential Access Boundary CEL path restriction, minting effectively bucket-wide GCS credentials. All four are fixed in Polaris 1.4.1. Per GHSA-w76p-3cgp-qfcm · Apache Polaris metadata write bypass (GitHub Advisory).
Apache Polaris tools repo ships Iceberg Catalog Migrator CLI + performance benchmarks. Per the apache/polaris-tools repository, the official tools project now hosts both performance benchmarks and an Iceberg Catalog Migrator CLI for moving tables between catalogs (Polaris ↔ Glue / Hive Metastore / Unity Catalog / Nessie). Catalog-migration tooling is the load-bearing piece for any organization committing to Polaris in 2026 — the question shifts from "will Polaris support migrations" to "how much does the migrator handle automatically."
Apache Ranger authorization plugin RFC in flight. Per the Apache Data Lakehouse Weekly (March 16 – April 2, 2026), Selvamohan Neethiraj opened an RFC for an Apache Ranger authorization plugin for Apache Polaris — bringing enterprise-grade policy integration to the open Iceberg REST Catalog reference implementation. The Ranger integration closes the "Unity Catalog has governance, Polaris doesn't" gap that has been the main reason enterprises picked UC over Polaris — and it shipped as Beta in Polaris 1.5.0 (see below).
Polaris 1.5.0 (May 18, 2026) turns the catalog into a control plane — and closes the governance gap. The release adds BigQuery Metastore federation (Polaris serves a unified Iceberg REST interface over tables managed in BigQuery Metastore), extends credential vending to the Generic Table API (new Polaris-Generic-Table-Access-Delegation header — short-lived, prefix-scoped storage credentials now cover non-Iceberg datasets, not just Iceberg tables), and refactors authorization into a fully pluggable Authorizer SPI (request-scoped AuthorizationRequest / AuthorizationDecision interfaces that separate the access decision from Polaris's internal principal resolution). The headline payoff is Apache Ranger support (Beta) — the enterprise-policy integration that had been the main reason organizations reached for Unity Catalog instead. Per Snowflake — Apache Polaris 1.5 Release and Apache Polaris 1.5.0 downloads.