BigQuery’s borderless Lakehouse lets you query data in Databricks Unity Catalog, Snowflake Horizon Catalog, and AWS Glue without moving it, using federated Iceberg tables accessed via four-part names and explored through conversational analytics. This guide walks through configuring each external catalog, granting permissions, running a multi-cloud join, and saving the result as a view for natural language exploration.
Configure Databricks Unity Catalog for federation
In Databricks, create a catalog and schema with a managed location pointing to your S3 bucket, then create an Iceberg table for product data. Enable External data access in the metastore settings and create a service principal, noting its UUID for later use.
In Google Cloud, set your project and region as environment variables, then run the gcloud command to create a federated Iceberg catalog of type unity, specifying your Databricks workspace URL, catalog name, and the service principal’s application ID with a five-minute refresh interval.
Describe the catalog to retrieve its generated service account ID, then in Databricks grant the service principal USE CATALOG on the catalog and USE SCHEMA, EXTERNAL USE SCHEMA, and SELECT on the schema to enable credential vending for external access.
Connect Snowflake and AWS Glue catalogs to BigQuery
For Snowflake, create a database and schema with an Iceberg table for customer data, then set up a dedicated reader role with USAGE on the database and schema and SELECT on the table. In Google Cloud, create a federated catalog of type snowflake using your account identifier, warehouse name (as the database), and reader role, then describe it to get the numeric service account ID.
Bind this ID to a Snowflake service user via Workload Identity Federation using the GCP type and the numeric subject. For AWS Glue, start with a placeholder trust policy, create an IAM role with a 12-hour session, then define permissions to read the Glue catalog and access S3 data, attaching the policy to the role.
Create the Iceberg table for store data in Athena, then in Google Cloud create a federated catalog of type glue using your AWS account ID, region, and role ARN. Extract the assigned service account ID and update the IAM role’s trust policy with the real Google Cloud values before enabling metadata synchronization.
Query across clouds and enable conversational analytics
In BigQuery, create a dataset and native fact table for sales data, then run a SQL query joining fact_sales with the federated product, customer, and store tables using their four-part names (project.catalog.namespace.table), noting that Snowflake identifiers appear uppercase while others are lowercase.
Save this join as a logical view to preserve the federated structure. Use BigQuery’s conversational analytics to ask natural language questions like 'Who are our top customers by total sales revenue, what products did they buy, and which stores did they shop at?', which the system translates into SQL, executes across clouds, and returns a unified response.
What to do next
Review the borderless Lakehouse documentation for supported regions and credential details, then try the hands-on codelab to practice federating catalogs step by step. For production, monitor metadata sync timing, query caching behavior, and encryption controls to align with data residency and security policies.
FAQ
Do I need to copy data into BigQuery to use federated Iceberg tables?
No, data remains in its original location; BigQuery computes the query using temporary credentials to read Parquet files directly from remote storage during execution.
What happens if metadata synchronization takes longer than the refresh interval?
If a sync cycle overruns, BigQuery skips the next scheduled run to prevent task queuing, ensuring only one metadata refresh process runs at a time.
Can I use customer-managed encryption keys for cached cross-cloud data blocks?
Cached blocks use Google-managed encryption keys; if your organization enforces the constraints/gcp.restrictNonCmekServices policy, BigQuery bypasses the cache and reads directly from remote storage for every query.
Source: Cross-cloud conversational analytics made simple with open standards (GCP).
