Google Cloud Plugs Snowflake Into Its Lakehouse Federation Layer
Google Cloud added Snowflake as a supported remote catalog provider for its cross-cloud Lakehouse on July 13, 2026. A second release note confirmed the capability on July 23. The feature is in preview. It connects Google Cloud's Lakehouse for Apache Iceberg to Snowflake Horizon Catalog through the open Iceberg REST Catalog (IRC) specification.
BigQuery and Managed Service for Apache Spark can now query Snowflake-managed Iceberg tables directly, without migrating files or building ETL pipelines.
This is a meaningful architectural shift for teams running workloads across both platforms.
What the Integration Actually Does
The Iceberg REST Catalog specification is the protocol that makes this possible. Every conforming catalog exposes a standard IRC endpoint. Every conforming engine connects as a client. When Google Cloud federates a Snowflake catalog, it creates a federated catalog object in Lakehouse. That object synchronizes metadata from Snowflake Horizon's IRC endpoints based on a refresh interval.
Access control works through short-lived credentials. When BigQuery requests table data, the catalog issues vended credentials — narrow, time-limited storage tokens — rather than standing bucket access. Neither engine gains persistent access to the other's underlying storage. Governance enforcement travels with the query, not just with the originating platform.
Snowflake Horizon Catalog layers RBAC, column-level masking, row access policies, data lineage, and audit logging on top of the basic IRC operations. The announcement does not state exactly which of those policy layers carry over to Google Cloud queries against federated tables. Teams should verify the specific enforcement boundary before granting access to sensitive columns.
Authentication has two supported paths. Secret-based authentication uses a Personal Access Token stored in Google Cloud Secret Manager. Workload Identity Federation uses OIDC token exchange, which requires ACCOUNTADMIN privileges in Snowflake to provision service users. Both paths require deliberate IAM role configuration on the Google Cloud side, including the BigLake Admin and Secret Manager Admin roles.
The Egress and Freshness Variables Teams Should Model First
Federated queries do not copy data, but they do move it. That creates two cost and performance variables that differ materially depending on network routing.
By default, queries to the remote catalog travel over the public internet. Standard TLS encryption applies. Egress costs follow the remote cloud provider's internet egress rates, and latency is variable. Teams already running Snowflake on AWS can configure a Dedicated Cross-Cloud Interconnect or Partner Cross-Cloud Interconnect instead. The private path reduces egress charges and makes latency more predictable.
The documentation does not state that the private interconnect option is available for Snowflake accounts on Google Cloud itself. Teams should verify the supported configurations for their specific Snowflake deployment region.
Metadata freshness is a separate variable. The refresh-interval flag on the federated catalog controls how often Lakehouse syncs table metadata from Snowflake Horizon. A shorter interval delivers fresher data. It also incurs additional API costs from the remote catalog provider. Teams running high-frequency analytics against tables that change often need to model that tradeoff.
The documentation also notes that Iceberg Metrics Reporting is not available for federated catalogs, which affects observability tooling that relies on that signal.
Google Cloud's cross-cloud Lakehouse caches remote data segments locally after the first query. Subsequent queries use the local cache, which reduces the portion of cross-cloud egress charged on repeat access. The announcement does not specify cache lifetime or eviction policy.
How the Catalog Architecture Fits Into a Multi-Engine Stack
Snowflake and Google Cloud frame this as a zero-copy, bidirectional architecture. Snowflake users interact with Google Cloud Lakehouse Iceberg tables using standard SQL through a Catalog-Linked Database (CLD). Google Cloud users reach Snowflake-managed tables through federated catalogs in Lakehouse. Both sides use the same IRC protocol. Neither side requires proprietary adapters.
For organizations already using Apache Polaris as a self-managed catalog, the architecture still applies. Apache Polaris is a popular open-source IRC implementation, originally co-created by Snowflake and Dremio and donated to the Apache Software Foundation. DIY catalogs are not serverless. They do not scale to zero when not in use. That creates an ongoing operational cost relative to managed options like Snowflake Horizon or Google Cloud's Lakehouse runtime catalog.
The Google Cloud documentation also lists Databricks Unity Catalog and AWS Glue as supported remote catalog providers, so this is not an exclusive Snowflake integration. Teams running a mixed estate of Snowflake and Databricks can federate both into a single Google Cloud Lakehouse catalog layer.
What Data Platform Owners Should Audit Now
This capability is in preview. That status matters for production planning. The announcement does not state a general availability timeline.
The practical decision for data platform owners centers on three questions before enabling federation.
First, identify which Snowflake tables you would actually federate. Not every table belongs in a cross-cloud query path. Tables with column-level masking or row access policies need explicit verification that those controls apply when BigQuery initiates the query.
Second, model the egress cost for your expected query volume. Run the estimate under both the public internet path and the private interconnect path if your Snowflake account is on AWS. The difference can be significant at scale. The private path also requires its own provisioning work.
Third, map the IAM role requirements on the Google Cloud side against your current permissions model. The setup requires BigLake Admin and Secret Manager Admin roles at minimum. Private interconnect routing adds Compute Network Admin and Service Directory roles. These are not lightweight grants in a least-privilege environment.
Teams that clear those three checks have a straightforward path to eliminating a class of ETL pipelines between the two platforms. Teams that skip the audit risk cost surprises and governance gaps that are harder to close after production traffic starts flowing.