Apache Polaris
Apache Polaris is an open-source catalog implementing the Iceberg REST specification, enabling interoperable, vendor-neutral table access across engines and clouds.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hostedManaged
PricingFree
Operational complexityMedium
WorkloadInteractiveBatch
LanguageJava
Use it when
- The catalog itself must stay vendor-neutral: an ASF project implementing the Iceberg REST specification that any compliant engine can use.
- You need real access control at the catalog layer: four-step RBAC over catalogs, namespaces, tables, and views, with OIDC identity and optional delegation to OPA.
- Engines should never hold long-lived storage keys; credential vending is precisely documented for S3, Azure, and GCS.
- Existing catalogs have to coexist: federation reaches any Iceberg REST catalog, and build-time extensions front a Hive or BigQuery metastore.
Think twice when
- Your tables are Delta or Hudi; the generic-table path for them is beta and separate from the Iceberg one.
- You want git-style branching, tagging, or cross-table commits, which is Nessie's territory; Polaris stops where the Iceberg spec stops.
- Nobody wants to operate a service: production means a Quarkus server plus PostgreSQL, where Glue or the Google catalog is zero-ops.
- Maturity is a gate: the project is still incubating at the ASF.
How it runs
A Java (Quarkus) server with a metastore behind it; PostgreSQL is the production backend and a Helm chart ships in the repository. It exposes the Iceberg REST API plus a management API for principals, roles, and grants. Maintenance policies (compaction, snapshot expiry, orphan removal) are defined and inherited in the catalog but executed by your engines. Vendors also operate it as a managed service.
Details
CompareHow Apache Polaris answers the questions Table Catalogs turns on.
Table Catalogs
| How it works | |
| Protocol | The Iceberg REST specification plus a Polaris Management API for the things the spec has no notion of, catalogs, principals, roles and grants. Federation runs outward and reaches furthest of the six: an Iceberg REST catalog anywhere, including another Polaris or AWS Glue, authenticated by OAuth2, bearer token, GCP or AWS SigV4, with optional build-time extensions federating to a Hive Metastore or BigQuery Metastore that stays the source of truth while Polaris brokers access |
| What it catalogs | Catalogs, nested namespaces, Iceberg tables and views, generic tables, and then the entities that make it administrable, principals, principal roles, catalog roles and grants. Policies are first-class too, and are themselves securable objects rather than settings on something else |
| Branching and versioning | Iceberg's own: snapshots, and no branching, tagging or cross-table history at the catalog level. This is the row Nessie is the exception to, and being the ASF reference implementation of the REST specification is precisely why it stops where the specification stops |
| Running it | |
| Maintenance | It runs none of it, and then does something no other row does, the policy framework defines schema-validated system policy types for data compaction, metadata compaction, snapshot expiry and orphan-file removal, attachable to a table, namespace or catalog and inherited downwards, carrying real settings like a target file size or a bin-pack strategy. The catalog standardises the instructions and an external engine executes them, which is a third answer beside "the catalog does it" and "nobody does it" |
| What you run | A Quarkus server and a metastore, with three backends and honest labels on them: PostgreSQL over JDBC is the production one, MongoDB is experimental and in beta, and the default in-memory store is documented as test-only and losing everything on restart. A Helm chart ships in the repository, and the metastore holds the entities, the RBAC data and the policies together |
| Connections | |
| Table formats | Iceberg first and properly (tables and views) with Delta and Hudi reachable through a separate generic-table framework that is still marked beta, holds a format string and a base location, and throws if an Iceberg table is loaded through it. The documentation's line that Polaris tables map to Iceberg, Delta or Hudi is true, and the two paths are genuinely separate |
| Engine support | Apache Doris, Flink, Spark, Dremio OSS, StarRocks and Trino are the engines the project names, and anything speaking the Iceberg REST API joins them. A Spark client ships in the repository for the generic-table path, since that framework sits outside the specification every other engine relies on |
| Access | |
| Access control | RBAC in four steps (a privilege is granted to a catalog role, the catalog role to a principal role, the principal role to a principal) over securable objects that include catalogs, namespaces, tables, views and policies. Identity comes from an internal store or an external OIDC provider, and for teams that already run policy elsewhere the decision itself can be delegated to an external policy decision point such as OPA |
| Storage credentials | The most precisely documented of the six, storage by storage: an STS AssumeRole on S3 with an inline session policy scoped to the table's locations and to read, list or write as the caller is authorised; a User Delegation SAS on Azure, capped at seven days by Azure rather than by Polaris; and a Credential Access Boundary downscoped OAuth2 token on GCS with optional service-account impersonation. Clients asking through X-Iceberg-Access-Delegation also get a credential-refresh endpoint, so a long query renews without reloading the table |
| Cost | |
| Billing unit | Nothing to meter: Apache-2.0 under the ASF with no commercial edition from the project. This is the one row here reachable both ways: run it yourself, or buy it operated by a vendor, which is what makes it the portability argument the other five are measured against |
Alternatives to Apache Polaris
