Catalog Federation

Time: ~7 minutes. Tangible win: explain what catalog federation lets Polaris do, and name the external catalog systems it can front.

Reading-only lesson Real organizations rarely start from zero — there's usually an existing Hive Metastore, an AWS Glue catalog, or a BigQuery metastore already holding tables before anyone adopts Polaris. Federation is how Polaris becomes the single entry point without a forced, all-at-once migration. Like the previous lesson, there's no bundled server for this locally, so the exercise is primary-source reading.

Catalog federation lets a single Polaris catalog proxy requests through to an external catalog system instead of managing entities itself — engines still talk to Polaris's REST endpoint, but Polaris forwards to (and translates responses from) the external system underneath.
As of this course's reference version, Polaris ships federation integrations for Iceberg REST catalogs (fronting another REST-catalog-speaking system), Hive Metastore, and BigQuery Metastore — each documented as a separate integration guide because the translation logic differs per backend.
The practical payoff mirrors Lesson 1's thesis at the org level: instead of every engine needing direct Hive Metastore and Glue and BigQuery drivers, they all speak one REST protocol to Polaris, and Polaris absorbs the differences.
Federation is a migration and interoperability tool, not a performance optimization — a federated call still round-trips to the external system; Polaris isn't caching or replacing that system's data.

Primary source Polaris Federation overview (1.7.0) and the Hive Metastore Federation guide (1.7.0).

Exercise (written, not scripted)

Read both guides linked above, then write 3–5 sentences on:

What configuration Polaris needs to federate to an existing Hive Metastore.
What would (and would not) change for an engine that was already talking to that Hive Metastore directly, once Polaris is federating to it instead.

Evidence of competence

A correct answer identifies that the engine now points at Polaris's REST endpoint instead of the Hive Metastore's Thrift endpoint (the client-facing protocol changes), while the actual catalog data continues to live in, and be governed by, the Hive Metastore underneath (the system of record does not move) — federation changes how you talk to the catalog, not where the catalog data lives, which is the same "changes access, not physical reality" pattern as Flight SQL in the Apache Arrow course.

Common failure modes Assuming federation migrates or copies the external catalog's data into Polaris — it doesn't; Polaris is a pass-through layer, and turning off federation (or the external system) removes Polaris's ability to see those tables at all. Also: expecting every external-catalog feature to be exposed identically through federation — the docs list federation integrations individually because each backend's capabilities and quirks are translated separately, not through one universal adapter.

Retrieval check

When Polaris federates to an existing Hive Metastore, where does the actual catalog data end up living?

Correct. Federation is a pass-through — the system of record doesn't move, only the client-facing protocol engines talk to changes.

Not quite. Federation never copies or migrates data into Polaris — the external system stays the system of record.

Which external catalog systems does Polaris ship federation integrations for, per the reference version this course covers?

Correct. Each is documented as a separate integration guide, since the translation logic differs per backend — there's no single universal federation adapter.

No. The reference version ships three named integrations, each with its own guide — not a universal adapter, and Glue isn't one of the three.

New terms — catalog federation — are in the glossary.

Ask the agent: "If my organization has both a Hive Metastore and a BigQuery Metastore, can one Polaris deployment federate to both at once, as two separate catalogs?" Next lesson turns everything covered as a single-node dev setup into a real understanding of what changes to run Polaris as durable, shared infrastructure.