Google Cloud Introduces BigQuery Cross-Cloud Caching to Slashing Lakehouse Egress and Latency

Google Cloud announced the public preview of cross-cloud caching for its borderless Lakehouse architecture in BigQuery, alongside the preview of BigQuery cross-cloud connections. The caching engine automatically retains frequently accessed remote datasets inside Google Cloud storage, significantly lowering cross-cloud network egress and query runtimes. Paired with standard Apache Iceberg columnar compression, Google Cloud reports that organizations can reduce the raw data transferred across cloud boundaries to under 5% of total processed query volume. Cross-cloud connections also modernize external compute patterns by using standard BigQuery compute workers in Google Cloud regions rather than deploying remote compute clusters in external environments. This release addresses a fundamental financial and architectural hurdle in multi-cloud operations. While lakehouse architectures centered on open table formats like Apache Iceberg and catalog federation (connecting to AWS Glue, Databricks Unity Catalog, or Snowflake Horizon) solved metadata interoperability, physical data egress across clouds remained notoriously expensive and slow. For enterprise platform architects, running routine analytics or grounding generative AI models on distributed operational data often required duplicating datasets through continuous ETL jobs. By introducing a transparent caching layer, BigQuery enables analytical and AI workloads to treat distributed cross-cloud datasets as localized assets without incurring continuous data transport penalties. This development fits into the broader enterprise trend toward open table formats and decoupled compute-storage architectures. As hyperscalers recognize that enterprise data will permanently remain fragmented across AWS, Azure, and GCP, the competitive focus has shifted from forcing data centralization into vendor-locked formats to providing the most efficient federation and execution engine. By leveraging Iceberg REST catalog specs and optimizing data transport layers, cloud providers are attempting to capture the compute and analytical layer even when the underlying object storage resides on a competitor's infrastructure. In practice, data teams should evaluate how this caching mechanism alters their data pipeline topologies. Teams maintaining scheduled cross-cloud replication jobs can begin retiring brittle ETL pipelines in favor of zero-copy federated queries with caching enabled. However, practitioners must account for cache warm-up overhead on initial runs and verify cache invalidation behaviors against high-frequency mutating datasets. Furthermore, while egress volume drops dramatically, organizations should audit local cache storage footprints and optimize partition pruning in upstream Iceberg tables to maximize cache hit ratios.