Google Cloud Introduces Cross-Cloud Caching to Cut Borderless Lakehouse Network Egress

Google Cloud announced the public preview of cross-cloud caching for its borderless Lakehouse and BigQuery cross-cloud connections. The update enables BigQuery workers to query remote Iceberg catalogs—such as AWS Glue, Snowflake Horizon, and Databricks Unity Catalog—as well as non-Iceberg external storage in Amazon Web Services and Microsoft Azure, while caching hot data partitions within the executing Google Cloud region. Before executing cached reads, BigQuery runs object metadata freshness checks against the source cloud to avoid stale query outputs, evicting unchanged entries automatically. For enterprise data architects and platform engineers, multi-cloud analytics has historically forced an architectural compromise: either continuously replicate massive datasets into a single provider or endure severe network latency and punishing data egress charges on live federated queries. By combining columnar data compression with local region caching, Google Cloud projects that organizations only need to pull roughly 3% to 5% of their total processed data across external networks on recurring analytical workloads. This shift allows data engineers to support multi-cloud analytics and agentic workflows without incurring uncontrollable interconnect costs. This release reflects a broader shift across major cloud vendors toward deep data federation over brute-force lift-and-shift consolidation. As enterprises maintain disparate workloads across AWS, Azure, and Google Cloud due to regional governance or best-of-breed tool adoption, hyperscalers are building protocol-level bridges. Integrating Apache Iceberg REST catalog federation alongside localized caching allows organizations to treat decentralized cloud data estates as a single logical data lake. In practice, platform teams should evaluate their active cross-cloud query patterns and quantify cache hit rates against remote metadata check latency. While cross-cloud caching dramatically curbs data transfer costs, organizations must still carefully design access policies and regional residency boundaries, as remote table partitions will reside locally inside Google Cloud's regional perimeter during the cache lifecycle.