Overview

Use Case

The Two Interoperability Patterns You Will Build

Prerequisites

What You'll Learn

What You'll Build

Regions must line up. Keep your GCS bucket, BigLake catalog, BigQuery datasets/connections, and Snowflake account in compatible regions to avoid cross-region latency and egress. This guide uses us-west1 on the Google side; substitute your own region consistently everywhere it appears.

Understanding the Architecture

Keyless by design. In both patterns Snowflake authenticates to Google using workload identity federation with an OAuth TOKEN_EXCHANGE grant. Snowflake presents a signed identity token; Google exchanges it for a short-lived access token scoped to the roles you grant a federated subject. There are no service-account keys to create, store, or rotate.

A note on names. In April 2026 Google rebranded BigLake to Lakehouse for Apache Iceberg and the BigLake metastore to the Lakehouse runtime catalog. The APIs, CLI (gcloud biglake), IAM roles, and endpoint hostname are unchanged and still say biglake, and Snowflake's documentation still refers to "BigLake." This guide uses BigLake to match the tooling.

Shared Setup: Project, Bucket, and Keyless Auth

Set your variables

export PROJECT_ID="<your-gcp-project>"
export REGION="us-west1"
export BUCKET="<your-unique-bucket-name>"
export POOL_ID="snowflake-pool"
export PROVIDER_ID="snowflake-oidc"

gcloud config set project "$PROJECT_ID"
export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format='value(projectNumber)')
echo "Project number: $PROJECT_NUMBER"

Enable the required APIs

gcloud services enable \
  biglake.googleapis.com \
  bigquery.googleapis.com \
  storage.googleapis.com \
  iam.googleapis.com \
  iamcredentials.googleapis.com \
  sts.googleapis.com \
  cloudresourcemanager.googleapis.com

Create the shared GCS bucket

gcloud storage buckets create "gs://$BUCKET" \
  --location="$REGION" \
  --uniform-bucket-level-access

Get Snowflake's identity issuer URL

USE ROLE ACCOUNTADMIN;
SELECT SYSTEM$GET_WORKLOAD_IDENTITY_ISSUER_URL();

export SNOWFLAKE_ISSUER_URL="<paste-the-issuer-url-here>"

Create the workload identity pool and OIDC provider

gcloud iam workload-identity-pools create "$POOL_ID" \
  --location=global \
  --display-name="Snowflake pool"

gcloud iam workload-identity-pools providers create-oidc "$PROVIDER_ID" \
  --location=global \
  --workload-identity-pool="$POOL_ID" \
  --issuer-uri="$SNOWFLAKE_ISSUER_URL" \
  --attribute-mapping="google.subject=assertion.sub"

export OAUTH_AUDIENCE="//iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$POOL_ID/providers/$PROVIDER_ID"
echo "$OAUTH_AUDIENCE"

Creating a WIF pool requires roles/iam.workloadIdentityPoolAdmin. If you grant it to yourself, allow ~60–90 seconds for the grant to propagate before the create commands succeed. If gcloud prompts hang in your shell, prefix commands with CLOUDSDK_CORE_DISABLE_PROMPTS=1.

Pattern A: Snowflake Writes, BigQuery Reads

Create the BigLake catalog (GCS flavour) and a namespace

gcloud biglake iceberg catalogs create "$BUCKET" \
  --catalog-type=gcs-bucket

gcloud biglake iceberg namespaces create "analytics" \
  --catalog="$BUCKET"

Turn on credential vending

gcloud biglake iceberg catalogs update "$BUCKET" \
  --credential-mode=vended-credentials

export BIGLAKE_SA="<paste-the-blirc-...-service-account>"
gcloud storage buckets add-iam-policy-binding "gs://$BUCKET" \
  --member="serviceAccount:$BIGLAKE_SA" \
  --role="roles/storage.objectUser"

Create the Snowflake catalog integration

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE CATALOG INTEGRATION biglake_int
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  REST_CONFIG = (
    CATALOG_URI = 'https://biglake.googleapis.com/iceberg/v1/restcatalog'
    CATALOG_NAME = 'gs://<your-unique-bucket-name>'
    ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS
    ADDITIONAL_HEADERS = ( "x-goog-user-project" = '<your-gcp-project>' )
  )
  REST_AUTHENTICATION = (
    TYPE = OAUTH
    OAUTH_GRANT_TYPE = TOKEN_EXCHANGE
    OAUTH_TOKEN_URI = 'https://sts.googleapis.com/v1/token'
    OAUTH_AUDIENCE = '<paste-your-OAUTH_AUDIENCE>'
    OAUTH_ALLOWED_SCOPES = ('https://www.googleapis.com/auth/bigquery')
  )
  ENABLED = TRUE;

Grant the federated subject its Google roles

DESC CATALOG INTEGRATION biglake_int;
-- copy the WORKLOAD_IDENTITY_FEDERATION_SUBJECT value

The federated subject changes every time you run CREATE OR REPLACE on the integration. If you recreate it, re-run DESC and re-apply the grants below.

export SUBJECT="<paste-WORKLOAD_IDENTITY_FEDERATION_SUBJECT>"
export MEMBER="principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$POOL_ID/subject/$SUBJECT"

gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="$MEMBER" --role="roles/serviceusage.serviceUsageConsumer" --condition=None
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="$MEMBER" --role="roles/biglake.viewer" --condition=None

Verify the integration

SELECT SYSTEM$VERIFY_CATALOG_INTEGRATION('biglake_int');

Create the catalog-linked database and write a table

CREATE OR REPLACE DATABASE biglake_db
  LINKED_CATALOG = ( CATALOG = 'biglake_int' );

USE DATABASE biglake_db;
USE SCHEMA analytics;

CREATE OR REPLACE ICEBERG TABLE customers (id INT, name STRING);
INSERT INTO customers VALUES (1, 'Ada'), (2, 'Grace'), (3, 'Alan');
SELECT * FROM customers ORDER BY id;

Read the same table live in BigQuery

SELECT * FROM `<your-unique-bucket-name>.analytics.customers` ORDER BY id;

Freshness in Pattern A is automatic. BigQuery reads the shared catalog on every query, so a new Snowflake INSERT is visible immediately on the next BigQuery SELECT. There is nothing to refresh.

BigQuery is read-only here today. Running DML (e.g. INSERT) against a GCS-flavour catalog table from BigQuery returns "DML statements are only supported over tables that have data stored in BigQuery." Bidirectional write to these tables is a Google preview feature (see What's Next). For BigQuery-side writes today, use Pattern B.

Pattern B: BigQuery Writes, Snowflake Reads

Create a BigQuery connection and grant it storage

bq mk --connection --location="$REGION" --connection_type=CLOUD_RESOURCE biglake_conn

# get the connection's service account
bq show --connection --location="$REGION" --format=json "$PROJECT_ID.$REGION.biglake_conn"
export CONN_SA="<paste the serviceAccountId from the output>"

gcloud storage buckets add-iam-policy-binding "gs://$BUCKET" \
  --member="serviceAccount:$CONN_SA" \
  --role="roles/storage.objectUser"

Create a dataset and a BigQuery-managed Iceberg table

CREATE SCHEMA IF NOT EXISTS bq_val OPTIONS (location = 'us-west1');

CREATE OR REPLACE TABLE `bq_val.drivers`
(
  driver_id   INT64,
  driver_name STRING
)
WITH CONNECTION `us-west1.biglake_conn`
OPTIONS (
  file_format = 'PARQUET',
  table_format = 'ICEBERG',
  storage_uri = 'gs://<your-unique-bucket-name>/blmt/drivers'
);

INSERT INTO `bq_val.drivers` VALUES (10, 'BQ-Alice'), (20, 'BQ-Bob');

Publish the latest metadata for external readers

EXPORT TABLE METADATA FROM `bq_val.drivers`;

Create the Snowflake catalog integration (BigQuery federation)

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE CATALOG INTEGRATION bq_fed_int
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  REST_CONFIG = (
    CATALOG_URI = 'https://biglake.googleapis.com/iceberg/v1/restcatalog'
    CATALOG_NAME = 'bq://projects/<your-gcp-project>'
    ACCESS_DELEGATION_MODE = EXTERNAL_VOLUME_CREDENTIALS
    ADDITIONAL_HEADERS = ( "x-goog-user-project" = '<your-gcp-project>' )
  )
  REST_AUTHENTICATION = (
    TYPE = OAUTH
    OAUTH_GRANT_TYPE = TOKEN_EXCHANGE
    OAUTH_TOKEN_URI = 'https://sts.googleapis.com/v1/token'
    OAUTH_AUDIENCE = '<paste-your-OAUTH_AUDIENCE>'
    OAUTH_ALLOWED_SCOPES = ('https://www.googleapis.com/auth/bigquery')
  )
  ENABLED = TRUE;

Create an external volume over the bucket

CREATE OR REPLACE EXTERNAL VOLUME bq_extvol
  STORAGE_LOCATIONS = (
    (
      NAME = 'gcs-drivers'
      STORAGE_PROVIDER = 'GCS'
      STORAGE_BASE_URL = 'gcs://<your-unique-bucket-name>/'
    )
  )
  ALLOW_WRITES = FALSE;

DESC EXTERNAL VOLUME bq_extvol;
-- copy STORAGE_GCP_SERVICE_ACCOUNT

Grant Google IAM to BOTH Snowflake principals

# 1) external-volume SA
export EXTVOL_SA="<paste STORAGE_GCP_SERVICE_ACCOUNT>"
gcloud storage buckets add-iam-policy-binding "gs://$BUCKET" \
  --member="serviceAccount:$EXTVOL_SA" --role="roles/storage.legacyBucketReader" --condition=None
gcloud storage buckets add-iam-policy-binding "gs://$BUCKET" \
  --member="serviceAccount:$EXTVOL_SA" --role="roles/storage.objectViewer" --condition=None

# 2) federated subject (re-DESC after any CREATE OR REPLACE)
export SUBJECT_B="<paste WORKLOAD_IDENTITY_FEDERATION_SUBJECT for bq_fed_int>"
export MEMBER_B="principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$POOL_ID/subject/$SUBJECT_B"
for ROLE in serviceusage.serviceUsageConsumer biglake.viewer bigquery.dataViewer storage.objectViewer; do
  gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="$MEMBER_B" --role="roles/$ROLE" --condition=None
done

Verify, then create the Snowflake Iceberg table and read

SELECT SYSTEM$VERIFY_CATALOG_INTEGRATION('bq_fed_int');
SELECT SYSTEM$VERIFY_EXTERNAL_VOLUME('bq_extvol');

CREATE OR REPLACE DATABASE bq_demo;
USE SCHEMA bq_demo.public;

CREATE OR REPLACE ICEBERG TABLE drivers
  CATALOG = 'bq_fed_int'
  EXTERNAL_VOLUME = 'bq_extvol'
  CATALOG_NAMESPACE = 'bq_val'
  CATALOG_TABLE_NAME = 'drivers';

SELECT * FROM drivers ORDER BY driver_id;

First activation can be slow. The very first bind of a brand-new cross-cloud external volume can loop on "Query needs to be retried to setup external volume" for a few minutes. This almost always means the external-volume SA is missing buckets.get — confirm the legacyBucketReader grant above — then wait and retry.

Prefer a whole database? You do not have to register tables one at a time. Both patterns can also be consumed as a catalog-linked database, which auto-mirrors every namespace/table from the catalog. Pattern B works the same as Pattern A here, except it needs the external volume (there is no vending on bq://):

CREATE OR REPLACE DATABASE bq_linked
  LINKED_CATALOG = ( CATALOG = 'bq_fed_int' )
  EXTERNAL_VOLUME = 'bq_extvol';
SELECT * FROM bq_linked.bq_val.drivers ORDER BY driver_id;

Keeping Readers in Sync

-- BigQuery
INSERT INTO `bq_val.drivers` VALUES (30, 'BQ-Carol');
EXPORT TABLE METADATA FROM `bq_val.drivers`;

-- Snowflake
ALTER ICEBERG TABLE bq_demo.public.drivers REFRESH;
SELECT * FROM bq_demo.public.drivers ORDER BY driver_id;

ALTER ICEBERG TABLE bq_demo.public.drivers SET AUTO_REFRESH = TRUE;

With AUTO_REFRESH = TRUE, Snowflake keeps the table current as BigQuery publishes new metadata. You can also have BigQuery publish metadata automatically on mutation for managed Iceberg tables; contact Google to enable that on your project if you want zero manual EXPORT TABLE METADATA calls.

Cleanup

Snowflake

USE ROLE ACCOUNTADMIN;

-- Pattern A
DROP DATABASE IF EXISTS biglake_db;              -- catalog-linked database
DROP CATALOG INTEGRATION IF EXISTS biglake_int;

-- Pattern B
DROP TABLE IF EXISTS bq_demo.public.drivers;
DROP DATABASE IF EXISTS bq_demo;
DROP DATABASE IF EXISTS bq_linked;               -- only if you built the CLD variant
DROP EXTERNAL VOLUME IF EXISTS bq_extvol;
DROP CATALOG INTEGRATION IF EXISTS bq_fed_int;

Google Cloud

# --- Pattern B: BigQuery table, dataset, and connection ---
bq rm -f -t "$PROJECT_ID:bq_val.drivers"
bq rm -f -d "$PROJECT_ID:bq_val"
bq rm --connection --location="$REGION" "$PROJECT_ID.$REGION.biglake_conn"

# --- Pattern A: BigLake table, namespace, and catalog ---
gcloud biglake iceberg tables delete customers \
  --namespace=analytics --catalog="$BUCKET" --quiet
gcloud biglake iceberg namespaces delete analytics \
  --catalog="$BUCKET" --quiet
gcloud biglake iceberg catalogs delete "$BUCKET" --quiet

# --- Shared: workload identity provider + pool ---
gcloud iam workload-identity-pools providers delete "$PROVIDER_ID" \
  --location=global --workload-identity-pool="$POOL_ID" --quiet
gcloud iam workload-identity-pools delete "$POOL_ID" --location=global --quiet

# --- Shared: the GCS bucket (removes all objects it holds) ---
gcloud storage rm --recursive "gs://$BUCKET"

On the IAM grants. The project-level role bindings you added to the federated subject (principal://.../subject/...) become inert the moment the workload identity pool is deleted, so there is nothing dangling to clean up. If you prefer to remove them explicitly, run gcloud projects remove-iam-policy-binding "$PROJECT_ID" --member=... --role=... for each role before deleting the pool. Deleting the BigQuery connection and BigLake catalog removes their auto-provisioned service accounts with them.

What's Next

Conclusion and Resources

What You Learned

Resources