BigQuery Access to 3rd Party Tables

By Chris Lipinski · 01st June 2025 · 5 min read

When a vendor or partner needs to share data stored in their GCP BigQuery project, there are two practical approaches: direct dataset access and authorised views. This guide walks through both, with SQL and gcloud examples from my experience implementing third-party data integrations.

Prerequisites

Before you begin, you will need:

A GCP project with the BigQuery API enabled
A service account in your project (recommended over user accounts for automation)
The third party's project ID and dataset name
Appropriate IAM permissions to assign roles (or a GCP admin who can)

Two Approaches

Direct dataset access — the third party grants your service account a reader role on their dataset. You query their tables directly using fully-qualified names. Simple, but exposes all tables in the dataset.

Authorised views — the third party creates a SQL view in a shared dataset that queries their private tables. They grant you access to the view only. You never see the underlying tables. This is the recommended approach for production integrations and the implementation our team utilised with our vendor.

Approach 1: Authorised Views (Recommended)

This is the most secure pattern. The third party controls exactly what data you can see by defining it in a view.

Step 1 — Third party creates a shared dataset and view

The third party creates a dataset (e.g. shared_data) and a view that selects from their private tables:

CREATE VIEW `vendor-project.shared_data.orders_view` AS
SELECT
    order_id,
    customer_name,
    order_date,
    total_amount
FROM `vendor-project.private_data.orders`
WHERE status = 'completed';

Step 2 — Third party authorises the shared dataset

The view's dataset must be authorised to access the source dataset. The third party runs:

bq mk --dataset --authorization=vendor-project:private_data \
    vendor-project:shared_data

Or via the GCP Console: BigQuery > Datasets > shared_data > Sharing > Authorize a dataset.

Step 3 — Third party grants your service account access

Grant your service account the Data Viewer role on the shared dataset:

gcloud projects add-iam-policy-binding vendor-project \
    --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/bigquery.dataViewer" \
    --condition="title=shared-dataset,expression=resource.name.startsWith('projects/vendor-project/datasets/shared_data')"

Step 4 — Query the view from your project

SELECT *
FROM `vendor-project.shared_data.orders_view`
LIMIT 100;

Your project pays for the query compute. The third party pays nothing.

Approach 2: Direct Dataset Access

Simpler to set up but less controlled. Use this for trusted internal integrations or testing.

Step 1 — Third party grants your service account the Data Viewer role

gcloud projects add-iam-policy-binding vendor-project \
    --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/bigquery.dataViewer"

Step 2 — Grant Job User so you can run queries

To submit query jobs you need the BigQuery Job User role on the project where the job runs. If you run the job from your own project, you already have this. If the job runs in the vendor's project, they must grant:

gcloud projects add-iam-policy-binding vendor-project \
    --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
    --role="roles/bigquery.jobUser"

Step 3 — Query the table directly

SELECT *
FROM `vendor-project.private_data.orders`
LIMIT 100;

IAM Roles Reference

roles/bigquery.dataViewer — Read access to tables and views in a dataset
roles/bigquery.jobUser — Submit query and load jobs (project-level)
roles/bigquery.user — Includes jobUser plus metadata read access
roles/bigquery.dataEditor — Read and modify table data
roles/bigquery.admin — Full BigQuery access (avoid for integrations)

Key Insights and Common Gotchas

UNRESOLVED errors on views

If you see UNRESOLVED errors when querying a view, it means the view's dataset has not been authorized to access the source dataset. The third party must complete Step 2 above.

Dataset-level vs project-level permissions

BigQuery roles can be applied at the project level or dataset level. For third-party access, always scope permissions to the specific dataset using IAM conditions. Project-level grants give access to all datasets, which is rarely what you want.

The querying project pays

BigQuery charges the project that runs the query job, not the project that stores the data. If you run the query from your project, you pay. This matters when sharing large datasets — agree on cost responsibility upfront.

Authorised view vs authorised dataset

An authorised view lets users query a view without access to the source tables. An authorised dataset does the same for all views within that dataset. Use authorised datasets when sharing multiple views from the same source data.