Google Cloud Previews Cross-Cloud Caching to Accelerate the Borderless Lakehouse

Google Cloud Pushes Cross-Cloud Analytics Further

Google Cloud has announced the preview of cross-cloud caching for its borderless Lakehouse, alongside BigQuery cross-cloud connections for querying data stored in other cloud environments.

The announcement addresses a common challenge in modern enterprise data estates: important information is distributed across multiple clouds, storage systems, operational databases, and SaaS platforms rather than residing in one environment.

Google Cloud says the new capabilities are designed to reduce the amount of data that needs to move between clouds while allowing organizations to query governed data where it already lives.

For organizations using services such as Amazon S3, Azure Data Lake Storage, Google Cloud Storage, operational databases, Salesforce, SAP, and Workday, this approach is intended to reduce reliance on traditional data movement patterns involving duplicated storage and ETL pipelines.

What Is the Borderless Lakehouse?

Google Cloud introduced its borderless Lakehouse earlier in 2026 as an architecture for querying and activating data across clouds without requiring organizations to move all of that data into a single location.

The approach uses the Apache Iceberg REST catalog specification to federate with catalogs including:

• Databricks Unity Catalog

• AWS Glue

• Snowflake Horizon

Google Cloud also introduced Partner Cross-Cloud Interconnect, which provides private, high-bandwidth connectivity to other cloud providers.

The latest announcement focuses on reducing the amount of data transferred across those connections in the first place.

What Is Cross-Cloud Caching?

Cross-cloud caching allows BigQuery to cache frequently accessed remote data locally in Google Cloud.

Instead of repeatedly retrieving the same information from another cloud, BigQuery can use previously cached data when appropriate.

Google Cloud says that combining standard Iceberg columnar compression with cross-cloud caching can mean that under 5% of the data processed may need to be transferred across clouds in applicable workloads.

The goal is to reduce network transfer and associated costs while improving the experience of repeated cross-cloud queries.

How the caching process works

The caching system operates at a granular level rather than simply copying entire files.

For columnar formats such as Apache Parquet, BigQuery can cache specific column chunks and dictionary pages required by a query.

The basic process is:

Query → Identify required data → Check local cache → Retrieve missing data remotely → Store required blocks → Reuse them in later queries

If the required data is not already cached, BigQuery retrieves it from the remote cloud and saves a local copy for subsequent queries.

Sub-file block granularity

One of the important technical details is the use of sub-file block granularity.

A query may only require a small number of columns from a multi-gigabyte Parquet file. Rather than transferring the entire file, the cache can operate on the specific column chunks and dictionary pages needed by the query.

This can reduce unnecessary network movement, particularly when analysts repeatedly explore the same datasets with different queries.

Encryption at rest

Google Cloud states that cached data blocks are encrypted at rest by default using Google-managed encryption keys, or GMEK.

The company says this allows temporary cache storage to maintain the security posture used by native BigQuery storage without requiring additional configuration.

Tenant and regional isolation

Cache entries are partitioned according to project and catalog boundaries.

Google Cloud also states that the Lakehouse keeps both local cache storage and query execution within the configured Google Cloud region.

For example, a workload configured for us-east4 remains anchored to that Google Cloud region, supporting regional data residency requirements when querying data stored in other clouds.

Freshness checks

Caching introduces an important question: how does a system avoid serving outdated information?

According to Google Cloud, BigQuery checks remote object metadata before using cached data. These checks help determine whether the underlying data has changed and whether the user still has access.

If an upstream table changes, BigQuery retrieves new files. Cached blocks that are no longer referenced can expire automatically.

A Cross-Cloud Example: Querying a 10 TiB Sales Table

Google Cloud illustrates the caching model using an e-commerce scenario.

The example involves a 10 TiB Iceberg sales table stored in Amazon S3 and federated into the Lakehouse through Databricks Unity Catalog.

During an evening promotional period, analysts query historical transaction data to identify storefronts associated with peak volume and revenue among high-intent demographics.

The example uses a BigQuery SQL query that joins sales information with household demographics, time, and website data.

A simplified portion of the query is:

SELECT
  w.web_name,
  hd.hd_buy_potential,
  COUNT(*) AS total_transactions,
  ROUND(SUM(ws.ws_sales_price), 2) AS total_sales
FROM `aws_lakehouse_catalog.sales.web_sales` ws
...
GROUP BY w.web_name, hd.hd_buy_potential;

The full source example uses the federated Iceberg table and additional joins.

First query: A cold cache

During the initial query, the local cache is empty.

Google Cloud's example shows:

cacheBytesRead: "0"

BigQuery applies partition pruning and column projection, retrieving only the required Parquet byte ranges from Amazon S3 through Partner Cross-Cloud Interconnect.

The example reports:

• Logical data processed: 214.5 GiB

• Data read from S3: 24.1 GiB

• Compression ratio: 8.9:1

• Cache: populated as the required blocks arrive in Google Cloud

The source explains that standard Iceberg columnar compression using Zstandard, or zstd, contributes to the reduction between logical data processed and data physically retrieved from S3.

What Happens When the Query Changes?

Analytics workloads rarely stop after one query.

In the example, the analyst modifies the query to include a shipping method dimension:

SELECT
  w.web_name,
  sm.sm_type,
  hd.hd_buy_potential,
  COUNT(*) AS total_transactions,
  ROUND(SUM(ws.ws_sales_price), 2) AS total_sales
FROM `aws_lakehouse_catalog.sales.web_sales` ws
JOIN `aws_lakehouse_catalog.sales.ship_mode` sm
  ON ws.ws_ship_mode_sk = sm.sm_ship_mode_sk
...
GROUP BY w.web_name, sm.sm_type, hd.hd_buy_potential;

Because much of the required data was already retrieved, BigQuery can reuse cached column chunks and only retrieve additional data required by the modified query.

The source reports the following results for this follow-on query:

• 94.8% cache hit rate

• 24.1 GiB served from the local cache

• 1.33 GiB transferred from S3 for the newly required data

• Existing cached column chunks reused even though the query changed

This illustrates the central concept behind granular caching: a modified query does not necessarily require the same data to be transferred again.

Why Compression and Cache Hits Matter for TCO

Google Cloud identifies two important factors when considering the cost of cross-cloud queries:

1. Compression ratio

2. Cache hit rate

The source provides an illustrative calculation using an assumed 8:1 compression ratio. Under that assumption, 1 TiB of logical data processed would require approximately 128 GiB of data to move across the network.

It then uses an assumed 80% cache hit rate. Under that scenario, only 20 GiB of every 100 GiB of physical data accessed would need to cross the network.

Combining those assumptions, Google Cloud states that approximately 26 GiB would need to be transferred for every 1 TiB of data processed, or less than 3% of the total logical data processed.

These figures are based on the assumptions specified in the source and should not be interpreted as a universal result for every cross-cloud workload.

For enterprises, the broader point is that both data compression and repeated access patterns can influence the amount of data that needs to cross cloud boundaries.

BigQuery Cross-Cloud Connections Enter Preview

Google Cloud is also previewing BigQuery cross-cloud connections.

These connections allow organizations to connect BigQuery directly to open-format data stored in Amazon S3 and Azure Storage.

The feature complements Lakehouse catalog federation, but the two approaches target different data scenarios.

Cross-cloud connections for raw files

Cross-cloud connections are intended for standalone files such as:

• CSV

• JSON

• Ad-hoc Parquet

When this data does not have an Iceberg catalog, cross-cloud connections can create BigQuery external tables that reference remote bucket paths directly.

Lakehouse federation for Iceberg data

Lakehouse catalog federation is designed for Iceberg datasets managed by catalogs such as:

• Databricks Unity Catalog

• AWS Glue

• Snowflake Horizon

Google Cloud says Lakehouse synchronizes schemas and table snapshots to simplify access to this type of data and help users query current data.

The distinction can be summarized as:

BigQuery Compute Stays in Google Cloud

Google Cloud says cross-cloud connections use standard BigQuery compute workers in Google Cloud regions rather than compute workers running in another cloud.

According to the announcement, this approach is intended to provide broader regional availability and full BigQuery feature parity, including BigQuery AI and Gemini capabilities when working with remote files.

The company also states that cross-cloud caching applies to data queried through both BigQuery cross-cloud connections and Lakehouse catalog federation.

What This Means for Multi-Cloud Data Architecture

The announcement highlights a broader industry shift toward architectures where organizations do not necessarily need to centralize every dataset before making it available for analytics and AI workloads.

Instead, the architecture described by Google Cloud combines several mechanisms:

Data remains in place

Organizations can keep data in existing cloud storage environments and expose it for querying.

Catalog federation provides context

For Iceberg datasets, catalog federation connects BigQuery with external data catalogs and their table metadata.

Cross-cloud connections address raw files

For data that is not managed through an Iceberg catalog, BigQuery cross-cloud connections provide a direct method for referencing external bucket paths.

Caching reduces repeated transfers

Once frequently accessed data is retrieved, granular caching can allow later queries to reuse locally available blocks.

Private connectivity supports cross-cloud movement

Partner Cross-Cloud Interconnect provides the network path for cloud-to-cloud data access described in the announcement.

Together, these components form the architecture Google Cloud is positioning as its borderless Lakehouse approach.

What Enterprises Should Watch

The preview introduces several areas that data engineering and cloud teams may want to evaluate in their own environments.

Query patterns

Caching is particularly relevant when workloads repeatedly access overlapping portions of remote datasets. Teams should examine which columns and datasets are accessed frequently.

Data freshness

Because cached data can potentially be reused, freshness controls are important. Google Cloud's approach includes remote metadata checks and retrieval of updated files when upstream tables change.

Data residency

Organizations with regional data requirements need to understand where cache storage and query execution occur. Google Cloud states that the Lakehouse anchors both to the configured Google Cloud region.

Cost modelling

Cross-cloud economics depend on factors such as compression and cache hit rates. The source's 8:1 compression and 80% cache-hit examples are assumptions for illustrating the model, not guaranteed workload results.

Data format

The choice between catalog federation and cross-cloud connections depends partly on whether data is managed as Iceberg tables or exists as standalone files.

Conclusion

Google Cloud's preview of cross-cloud caching extends its borderless Lakehouse strategy by focusing on the amount of data that actually needs to move between clouds.

The architecture combines Iceberg-based catalog federation, granular caching, cross-cloud connections and private cloud connectivity. The source's e-commerce example demonstrates how a first query can populate a local cache and how a modified follow-on query can reuse previously retrieved column chunks.

At the same time, BigQuery cross-cloud connections broaden the approach beyond Iceberg by allowing direct access to raw files in Amazon S3 and Azure Storage.

For organizations operating across multiple cloud environments, the development reflects growing demand for analytics architectures that can work with distributed data without requiring every dataset to be copied into one location.