10. Catalog Federation
Making tables registered in one catalog visible through another, without copying data or metadata. The answer to "we have two catalogs and can't get rid of either."
Both directions were checked on 2026-09-25. Into GCP: the Lakehouse runtime catalog's federated catalogs (Preview), per the cross-cloud data access overview. Out of GCP: Databricks Unity Catalog federation (Beta) and Snowflake catalog integration (GA on Snowflake's side), per each vendor's docs. Re-verify before any client deliverable — every integration here is under a year old.
What catalog federation is
One table, two catalogs, one owner
A federated catalog exposes tables whose metadata authority is another catalog. Reads resolve through to the owning catalog; the data files stay where they are.
What it is not
- Query federation — one engine querying another system over a connector (Trino's federation, BigQuery federated queries, Databricks Lakehouse Federation connections). The remote system does the work.
- Catalog sync or mirroring — metadata copied on a schedule into a second catalog. Two copies that can drift.
- A shared REST catalog — several engines talking to one Iceberg REST catalog directly (Module 04). No federation needed, and usually the better answer.
Why the distinction matters
Each option has a different freshness guarantee, write story, and governance model. Clients use "federation" for all of them; pin down which one is meant before designing anything.
Why it comes up
Two platforms that both bring a catalog
BigQuery with the Lakehouse runtime catalog on one side, Databricks with Unity Catalog on the other (Module 09). Neither team will give up its catalog.
Multi-cloud and acquisitions
An AWS Glue or Unity Catalog estate elsewhere that GCP engines need to read.
Migration bridges
Reading a legacy Hive Metastore (Module 05) through a newer catalog while tables move across.
Federation on GCP
In both directions the files exist once and one catalog owns each table; the other catalog is a window onto it.
Into the GCP catalog
A federated catalog in the Lakehouse runtime catalog links to a remote Iceberg REST catalog — Databricks Unity Catalog, AWS Glue (including S3 Tables), Snowflake Horizon, SAP Business Data Cloud, or Workday Data Lake — authenticated through Secret Manager or OIDC token federation. Its tables appear as project.federated_catalog.namespace.table to BigQuery and to Spark with credential vending. Google is explicit that "federated catalogs in Lakehouse are read-only views of the remote catalog". Only Iceberg tables sync: Snowflake native tables and Databricks default-storage tables are ignored.
When the source is in another cloud
Glue, and Unity or Horizon on AWS, put the data files in another cloud. Transport, caching, egress, residency, and CMEK then dominate the design — covered in Module 11. Unity or Horizon on Google Cloud is same-cloud federation, and none of that applies.
Out of the GCP catalog
- Databricks — Unity Catalog's Google Cloud Lakehouse catalog federation (Beta on Databricks on GCP) reads both Lakehouse runtime catalog tables and BigQuery-managed Iceberg tables. Read-only. Details in Module 09.
- Snowflake — a catalog integration to the Lakehouse REST endpoint plus a catalog-linked database (GA on Snowflake's side since 2026-06-02); Google lists Snowflake read/write interop as Preview.
- Starburst — Starburst Enterprise connects through the REST endpoint; Galaxy does not yet.
No AWS-side reader of the GCP catalog was found.
Direct access instead of federation
When every engine can speak Iceberg REST to the GCP catalog, point them at it directly and skip federation entirely.
Ownership and writes
One writer catalog per table
Federated access is typically read-only. Decide which catalog owns each table and route every write through it.
What goes wrong without a rule
Two catalogs committing to the same table, each unaware of the other's snapshots — lost writes and corrupted table state.
Maintenance follows ownership
Compaction and snapshot expiry run from the owning side. A federated reader must not run maintenance.
Freshness and performance
Metadata caching
A Lakehouse federated catalog re-syncs on a --refresh-interval that is either disabled or at least 300 seconds; an overrunning refresh skips the next one, and remote deletes appear only after the next successful refresh. Plan for at least five minutes of metadata lag — the same failure mode as Module 04's stale pinned metadata.
Cross-cloud reads
Federating a catalog does not move the data. Reading files across clouds means egress cost and latency on every uncached read — Module 11 covers the caching, transport, and residency details.
Governance
Policies do not federate
Grants, masks, and row filters defined in the owning catalog do not automatically apply in the federating one. Each side needs its own policy, kept in agreement. Google does not document whether BigQuery row access policies or masking can be applied over federated tables — test before promising it.
Identity and credentials
Which identity the federated read uses, how credentials are vended across platforms, and whose audit log records the access.
When to use catalog federation
Decision gates
Two catalogs are a fixed constraint; the federated side only needs to read; and metadata staleness within the cache window is acceptable.
Anti-patterns
Federating when a shared Iceberg REST catalog would do; using federation for bidirectional writes; federating across clouds for high-frequency queries without costing the egress; and assuming the owning catalog's governance carries over.