BigQuery cross-cloud caching for S3 and Azure data is GA at no extra charge

Google Cloud has made cross-cloud caching in its Lakehouse generally available for BigQuery, according to the BigQuery release notes entry dated November 2, 2026. The feature keeps file blocks that BigQuery has already read from Amazon S3 or Azure Blob Storage in Google Cloud, so later queries that touch the same blocks read them locally instead of pulling them again across clouds. Google states that enabling caching carries no additional charge, and it presents the feature as a way to reduce cross-cloud egress costs and speed up repeated queries.

The release is opt-in. The current documentation says cross-cloud caching is disabled by default, and an administrator turns it on when creating or updating a Lakehouse federated catalog or a BigQuery cross-cloud connection. For teams that run BigQuery dashboards, scheduled reports or notebooks against Iceberg tables cataloged in AWS Glue, Databricks Unity Catalog or Snowflake Horizon Catalog, the setting decides whether every refresh pays to move the same files out of the other cloud again.

··········

WHAT GOOGLE ANNOUNCED FOR BIGQUERY CROSS-CLOUD CACHING.

The November 2 release notes describe Lakehouse caching for cross-cloud data access as generally available. The entry states that cross-cloud caching is disabled by default and that customers can opt in on a Lakehouse federated catalog or on a BigQuery cross-cloud connection.

The Lakehouse page "About cross-cloud data access", last updated on November 3, 2026, explains the mechanism. When a query reads remote file blocks with caching enabled, Lakehouse keeps those blocks. Later queries, including different queries that read the same blocks, are served from the local cache. The page limits the feature to files in Amazon S3 and Azure Blob Storage, and it says Google manages cache capacity, retention and eviction automatically. No retention period or cache size is published.

Before cached data is served, every query checks metadata and access permissions with the remote storage source. Google describes this as the protection against stale reads and against a revoked permission being bypassed through the cache. For a BI developer, a user who loses access to a table in the source cloud does not keep reading it from a cached copy in BigQuery.

··········

WHICH CATALOGS AND CLOUDS THE LAKEHOUSE CACHE COVERS.

The cross-cloud data access page lists the catalogs that BigQuery can federate, and the caching statement applies to the files those catalogs point to in S3 or Azure Blob Storage. The page does not tie caching to a specific catalog, so the table below shows the documented catalog and cloud pairs together with the storage condition for caching.

........

Catalog	Hosting clouds listed	Caching applies to
Databricks Unity Catalog	AWS, Azure, Google Cloud	Files in S3 or Azure Blob Storage
AWS Glue	AWS	Files in S3
Snowflake Horizon Catalog	AWS, Azure, Google Cloud	Files in S3 or Azure Blob Storage
Workday Data Lake	AWS, Google Cloud	Files in S3
SAP Business Data Cloud	AWS, Azure, Google Cloud	Files in S3 or Azure Blob Storage

........

The documentation describes caching only for files in S3 and Azure Blob Storage, so tables whose files already sit in Google Cloud Storage are outside its scope. The separate "Supported regions and capabilities" page, updated on November 3, maps each AWS region to its closest Google Cloud region, for example us-east-1 to us-east4 and eu-central-1 to europe-west3. For Azure, the page gives no region table and advises creating the federated catalog in the Google Cloud region closest to the Azure region and the interconnect location.

··········

HOW CACHING CHANGES CROSS-CLOUD QUERY COSTS IN BIGQUERY.

Google's pricing statement is short: enabling caching has no additional charge. The documentation does not publish a cache storage price, and it does not quantify savings. It says the egress reduction depends on query patterns, on how often the source files change and on how long blocks stay in the cache in the target region. The egress itself is billed under the networking terms of the cloud that hosts the files, and the documentation notes that internet egress is typically higher than private interconnect rates.

Caching is separate from the network path. The same page describes two transport choices for query data: the public internet over TLS, which is the default and carries standard egress charges and variable latency, and a private interconnect through Dedicated or Partner Cross-Cloud Interconnect, available for Amazon S3 and Azure Data Lake Storage Gen2. Google lists better security, potentially lower egress costs and more consistent latency for the interconnect route. A team can combine the two: caching cuts how many bytes cross clouds, and the interconnect changes the route and rate of the bytes that still do.

The workloads that gain the most are repetitive ones, while a table whose files are rewritten on every load gives the cache little to reuse. A dashboard that refreshes the same fact table several times a day, a scheduled query that rebuilds a summary each morning, or analysts exploring the same partitions all read many identical blocks.

··········

MEASURING CACHE BYTES AND REMOTE BYTES IN BIGQUERY JOB STATISTICS.

BigQuery reports the effect of the cache per job. The Lakehouse documentation points to the objectStorageStats field of the query job statistics, a list with one entry per cloud provider accessed. Each entry contains cloudProvider (for example AWS or AZURE), cacheBytesRead for bytes served from the local cache, and objectStorageBytesRead for bytes read directly from the remote object storage. The "Query remote data" page shows how to read these statistics for a job with the bq tool:

bq show --format=prettyjson --job=true JOB_ID

The values appear under statistics.query.objectStorageStats in the output, and the same job details can be inspected in the BigQuery console. Remote tables are addressed with a four-part path of the form project, federated catalog, namespace and table, as in the documentation's pattern:

SELECT *
FROM `PROJECT_ID.FEDERATED_CATALOG_NAME.NAMESPACE_NAME.TABLE_NAME`
LIMIT 10;

The worked example below shows how a BI team can turn the two byte counters into a share of data served locally. The figures are illustrative: a dashboard query that reads 400 GiB of S3 files runs once a day for a week, and about 5% of the files change between runs.

........

Run (illustrative)	cacheBytesRead (GiB)	objectStorageBytesRead (GiB)	Share from cache
Monday	0	400	0.0%
Tuesday	380	20	95.0%
Wednesday	380	20	95.0%
Thursday	380	20	95.0%
Friday	380	20	95.0%
Week total	1,520	480	76.0%

........

Without the cache, the five runs would read 2,000 GiB from S3. With it, the remote reads fall to 480 GiB, which is 1,520 GiB, or 76.0%, fewer bytes leaving AWS for the week. The first run always reads from the remote storage, so the weekly share depends heavily on how many times the same data is queried after it has been cached. To convert the byte reduction into dollars, a team multiplies it by the egress rate on its own AWS or Azure bill; Google does not publish that figure for the other clouds. For more on how BigQuery handles documents and files stored in the lakehouse, see the recent piece on BigQuery AI.PARSE_DOCUMENT reaching general availability.

··········

DATA RESIDENCY, CMEK AND GOVERNANCE LIMITS OF LAKEHOUSE CACHING.

The cache creates temporary copies of remote data inside Google Cloud. The documentation states that cached data is stored within the Google Cloud query execution region, and it gives the example of files hosted in the EU being queried from us-east4. In that case the cached blocks are stored in the US region. Google asks customers to confirm that storing those copies in the target region meets their data residency and compliance requirements, which in practice means a review by the data protection or security team before the setting is enabled on catalogs holding personal or regulated data.

Encryption follows a fixed rule. Cached data is encrypted at rest with Google-owned and Google-managed keys, and customer-managed encryption keys are not supported for the cache. Where the organization policy constraint constraints/gcp.restrictNonCmekServices applies, Lakehouse disables caching for queries that access the restricted tables. Those queries still run and read directly from the remote storage, so a team under that policy will see objectStorageBytesRead stay at the full volume even after turning caching on.

Identity and access are unchanged by the cache. To query federated data, the documentation lists the BigQuery Data Viewer, BigQuery Job User and BigLake Viewer roles, and creating a cross-cloud connection requires BigQuery Admin or equivalent permissions on the project, plus the matching administrative roles in AWS or Azure. Service identity is the default for cross-cloud access, and user identity federation is currently supported only for Databricks Unity Catalog. Teams that already share open table formats across platforms, as in Snowflake Open Data Sharing for Iceberg tables, face the same residency review whenever a copy of the data lands in a second cloud.

··········

WHAT TO CHECK BEFORE ENABLING CACHING ON A FEDERATED CATALOG.

The Google Cloud documentation is not fully aligned yet. The "Query remote data" page, last updated on October 27, 2026, still describes Lakehouse caching as enabled automatically for all cross-cloud queries and labels the feature as Preview, while the release notes of November 2 and the cross-cloud data access page of November 3 describe a generally available feature that is off by default. The newer pages carry the GA status, but a team should confirm the actual setting on each existing catalog and connection rather than assume either behavior. The documentation also does not give the exact console field, bq flag or API field for the opt-in, so the setting has to be located in the create or update flow of the catalog or connection.

A short review list covers most deployments. Confirm which federated catalogs or connections read files in S3 or Azure Blob Storage. Check the query execution region against the data's home region and the residency rules that apply to it. Check whether the CMEK organization policy covers the tables. Then compare objectStorageBytesRead before and after enabling the cache on a few recurring jobs, and multiply the difference by the egress rate on the source cloud's bill. BI teams that serve the results to spreadsheet users can also look at how conversational analytics in Connected Sheets puts BigQuery data in front of business users, since every refresh of such a sheet on federated tables is another cross-cloud read.

··········

BIGQUERY CROSS-CLOUD CACHING: WHAT GOOGLE CONFIRMS AND WHAT DEPENDS ON YOUR SETUP.

Google confirms that cross-cloud caching for BigQuery and Lakehouse is generally available as of November 2, 2026, that it is disabled by default, that it is enabled per federated catalog or cross-cloud connection, that it applies to files in Amazon S3 and Azure Blob Storage, that enabling it carries no additional charge, that CMEK is not supported for cached data, and that job statistics expose cacheBytesRead and objectStorageBytesRead for each cloud provider.

The savings depend on the workload and the contract. How much egress disappears depends on how often the same blocks are read, how often files change and how long Google keeps them cached, and none of those retention details is published. The dollar value depends on the egress terms of AWS or Azure and on whether traffic runs over the public internet or a Cross-Cloud Interconnect. Google has not disclosed cache capacity, a retention period, a per-provider support matrix for caching or the exact configuration field, so the job statistics of a team's own recurring queries remain the reliable way to measure what the feature delivers.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org