BigQuery locations
This page explains the concept of location and the different regions where data can be stored and processed. Pricing for storage and analysis is also defined by location of data and reservations. For more information about pricing for locations, see BigQuery pricing. To learn how to set the location for your dataset, see Create datasets. For information about reservation locations, see Managing reservations in different regions.
For more information about how the BigQuery Data Transfer Service uses location, see Data location and transfers.
Locations and regions
BigQuery provides two types of data and compute locations:
A region is a specific geographic place, such as London.
A multi-region is a large geographic area, such as the United States, that contains two or more regions. Multi-region locations can provide larger quotas than single regions.
For either location type, BigQuery automatically stores copies of your data in two different Google Cloud zones within a single region in the selected location. For more information about data availability and durability, see Reliability: Disaster planning.
Supported locations
BigQuery datasets can be stored in the following regions and multi-regions. For more information about regions and zones, see Geography and regions.
Regions
The following table lists the regions in the Americas where BigQuery is available.Region description | Region name | Details |
---|---|---|
Columbus, Ohio | us-east5 |
|
Dallas | us-south1 |
Low CO2 |
Iowa | us-central1 |
Low CO2 |
Las Vegas | us-west4 |
|
Los Angeles | us-west2 |
|
Montréal | northamerica-northeast1 |
Low CO2 |
Northern Virginia | us-east4 |
|
Oregon | us-west1 |
Low CO2 |
Salt Lake City | us-west3 |
|
São Paulo | southamerica-east1 |
Low CO2 |
Santiago | southamerica-west1 |
Low CO2 |
South Carolina | us-east1 |
|
Toronto | northamerica-northeast2 |
Low CO2 |
Region description | Region name | Details |
---|---|---|
Delhi | asia-south2 |
|
Hong Kong | asia-east2 |
|
Jakarta | asia-southeast2 |
|
Melbourne | australia-southeast2 |
|
Mumbai | asia-south1 |
|
Osaka | asia-northeast2 |
|
Seoul | asia-northeast3 |
|
Singapore | asia-southeast1 |
|
Sydney | australia-southeast1 |
|
Taiwan | asia-east1 |
|
Tokyo | asia-northeast1 |
Region description | Region name | Details |
---|---|---|
Belgium | europe-west1 |
Low CO2 |
Berlin | europe-west10 |
Low CO2 |
Finland | europe-north1 |
Low CO2 |
Frankfurt | europe-west3 |
Low CO2 |
London | europe-west2 |
Low CO2 |
Madrid | europe-southwest1 |
Low CO2 |
Milan | europe-west8 |
|
Netherlands | europe-west4 |
Low CO2 |
Paris | europe-west9 |
Low CO2 |
Turin | europe-west12 |
|
Warsaw | europe-central2 |
|
Zürich | europe-west6 |
Low CO2 |
Region description | Region name | Details |
---|---|---|
Dammam | me-central2 |
|
Doha | me-central1 |
|
Tel Aviv | me-west1 |
Region description | Region name | Details |
---|---|---|
Johannesburg | africa-south1 |
Multi-regions
The following table lists the multi-regions where BigQuery is available.Multi-region description | Multi-region name |
---|---|
Data centers within member states of the European Union1 | EU |
Data centers in the United States2 | US |
1 Data located in the EU
multi-region is only
stored in one of the following locations: europe-west1
(Belgium) or europe-west4
(Netherlands).
The exact location in which the data is stored and processed is determined automatically by BigQuery.
2 Data located in the US
multi-region is only
stored in one of the following locations: us-central1
(Iowa),
us-west1
(Oregon), or us-central2
(Oklahoma). The exact
location in which the data is stored and processed is determined
automatically by BigQuery.
BigQuery Studio locations
BigQuery Studio lets you save, share, and manage versions of code assets such as notebooks and saved queries.
The following table lists the regions where BigQuery Studio is available:
Region description | Region name | Details | |
---|---|---|---|
Africa | |||
Johannesburg | africa-south1 |
||
Americas | |||
Columbus | us-east5 |
||
Dallas | us-south1 |
Low CO2 | |
Iowa | us-central1 |
Low CO2 | |
Los Angeles | us-west2 |
||
Las Vegas | us-west4 |
||
Montréal | northamerica-northeast1 |
Low CO2 | |
N. Virginia | us-east4 |
||
Oregon | us-west1 |
Low CO2 | |
São Paulo | southamerica-east1 |
Low CO2 | |
South Carolina | us-east1 |
||
Asia Pacific | |||
Hong Kong | asia-east2 |
||
Jakarta | asia-southeast2 |
||
Mumbai | asia-south1 |
||
Seoul | asia-northeast3 |
||
Singapore | asia-southeast1 |
||
Sydney | australia-southeast1 |
||
Taiwan | asia-east1 |
||
Tokyo | asia-northeast1 |
||
Europe | |||
Belgium | europe-west1 |
Low CO2 | |
Frankfurt | europe-west3 |
Low CO2 | |
London | europe-west2 |
Low CO2 | |
Madrid | europe-southwest1 |
Low CO2 | |
Netherlands | europe-west4 |
Low CO2 | |
Turin | europe-west12 |
||
Zürich | europe-west6 |
Low CO2 | |
Middle East | |||
Doha | me-central1 |
||
Dammam | me-central2 |
BigQuery Omni locations
BigQuery Omni processes queries in the same location as the dataset that contains the tables you're querying. After you create the dataset, the location cannot be changed. Your data resides within your AWS or Azure account. BigQuery Omni regions support Enterprise edition reservations and on-demand compute (analysis) pricing. For more information about editions, see Introduction to BigQuery editions.Region description | Region name | Colocated BigQuery region | |
---|---|---|---|
AWS | |||
AWS - US East (N. Virginia) | aws-us-east-1 |
us-east4 |
|
AWS - US West (Oregon) | aws-us-west-2 |
us-west1 |
|
AWS - Asia Pacific (Seoul) | aws-ap-northeast-2 |
asia-northeast3 |
|
AWS - Asia Pacific (Sydney) | aws-ap-southeast-2 |
australia-southeast1 |
|
AWS - Europe (Ireland) | aws-eu-west-1 |
europe-west1 |
|
AWS - Europe (Frankfurt) | aws-eu-central-1 |
europe-west3 |
|
Azure | |||
Azure - East US 2 | azure-eastus2 |
us-east4 |
BigQuery ML locations
BigQuery ML processes and stages data in the same location as the dataset that contains the data.
BigQuery ML stores your data in the selected location in accordance with the Service Specific Terms.
BigQuery ML model prediction and other ML functions are supported in all BigQuery regions. Support for model training varies by region:
Training for internally trained models and imported models is supported in all BigQuery regions.
Training for autoencoder, boosted tree, DNN, and wide-and-deep models is available in the multi-regions
US
andEU
, and most single regions. For more information, see Locations for all other types of models.Training for AutoML is supported in the
US
andEU
multi-regions and in most single regions.
Locations for remote models
This section contains more information about supported locations for remote models, and about where remote model processing occurs.Regional locations
The following table shows which regions are supported for different types of remote models. The column name indicates the type remote model.Region description | Region name | Vertex AI deployed models | Text generation LLMs | Text embedding LLMs | Cloud Natural Language API | Cloud Translation API | Cloud Vision API | Document AI API | Speech-to-Text API | |
---|---|---|---|---|---|---|---|---|---|---|
Americas | ||||||||||
Columbus, Ohio | us-east5 |
|||||||||
Dallas | us-south1 |
● | ● | |||||||
Iowa | us-central1 |
● | ● | ● | ● | |||||
Las Vegas | us-west4 |
● | ● | ● | ||||||
Los Angeles | us-west2 |
● | ||||||||
Montréal | northamerica-northeast1 |
● | ● | ● | ||||||
Northern Virginia | us-east4 |
● | ● | ● | ||||||
Oregon | us-west1 |
● | ● | ● | ● | |||||
Salt Lake City | us-west3 |
● | ||||||||
São Paulo | southamerica-east1 |
● | ● | |||||||
Santiago | southamerica-west1 |
|||||||||
South Carolina | us-east1 |
● | ● | ● | ||||||
Toronto | northamerica-northeast2 |
● | ||||||||
Europe | ||||||||||
Belgium | europe-west1 |
● | ● | ● | ● | |||||
Finland | europe-north1 |
● | ||||||||
Frankfurt | europe-west3 |
● | ● | ● | ● | |||||
London | europe-west2 |
● | ● | ● | ● | |||||
Madrid | europe-southwest1 |
|||||||||
Milan | europe-west8 |
● | ● | ● | ||||||
Netherlands | europe-west4 |
● | ● | ● | ● | |||||
Paris | europe-west9 |
● | ● | ● | ||||||
Turin | europe-west12 |
|||||||||
Warsaw | europe-central2 |
● | ||||||||
Zürich | europe-west6 |
● | ● | |||||||
Asia Pacific | ||||||||||
Delhi | asia-south2 |
|||||||||
Hong Kong | asia-east2 |
● | ● | |||||||
Jakarta | asia-southeast2 |
● | ||||||||
Melbourne | australia-southeast2 |
|||||||||
Mumbai | asia-south1 |
● | ● | ● | ||||||
Osaka | asia-northeast2 |
|||||||||
Seoul | asia-northeast3 |
● | ● | ● | ||||||
Singapore | asia-southeast1 |
● | ● | ● | ● | |||||
Sydney | australia-southeast1 |
● | ● | ● | ||||||
Taiwan | asia-east1 |
● | ● | |||||||
Tokyo | asia-northeast1 |
● | ● | ● | ● | |||||
Middle East | ||||||||||
Dammam | me-central2 |
|||||||||
Doha | me-central1 |
|||||||||
Tel Aviv | me-west1 |
● | ● |
Multi-regional locations
The following table shows which multi-regions are supported for different types of remote models. The column name indicates the type remote model.Region description | Region name | Vertex AI deployed models | Text generation LLMs | Text embedding LLMs | Cloud Natural Language API | Cloud Translation API | Cloud Vision API | Document AI API | Speech-to-Text API |
---|---|---|---|---|---|---|---|---|---|
Data centers within member states of the European Union1 | EU |
● | ● | ● | ● | ● | ● | ||
Data centers in the United States | US |
● | ● | ● | ● | ● | ● | ● |
Processing locations for hosted Google models
For remote models over Google model hosted in Vertex AI, the processing location is affected by the location of the dataset in which the remote models resides.
If the dataset in which you are creating the remote model is in a single region,
the Vertex AI model endpoint must be in the same region. If
you specify the model endpoint URL, use the endpoint in the same region
as the dataset. For example, if the dataset is in the us-central1
region, then
specify the endpoint
https://us-central1-aiplatform.googleapis.com/v1/projects/myproject/locations/us-central1/publishers/google/models/<target_model>
.
If you specify the model name, BigQuery ML automatically
chooses the endpoint in the correct region.
If the dataset in which you are creating the remote model is in a multi-region,
then the Vertex AI model endpoint must be in a region within
that multi-region. For example, if the dataset is in the eu
multi-region,
then you could specify the URL for the europe-west6
region endpoint,
https://europe-west6-aiplatform.googleapis.com/v1/projects/myproject/locations/europe-west6/publishers/google/models/<target_model>
.
If you specify the model name instead of the endpoint URL,
BigQuery ML defaults to using the europe-west4
endpoint for
datasets in the eu
multi-region, and to using the us-central1
endpoint for
datasets in the us
multi-region.
Locations for all other types of models
This section contains more information about supported locations for all model types other than remote models.Regional locations
Region description | Region name | Imported models |
Built-in model training |
DNN/Autoencoder/ Boosted Tree/ Wide-and-Deep models training |
AutoML model training |
Hyperparameter tuning |
Vertex AI Model Registry integration | ||
---|---|---|---|---|---|---|---|---|---|
Americas | |||||||||
Columbus, Ohio | us-east5 |
● | ● | ||||||
Dallas | us-south1 |
● | ● | ||||||
Iowa | us-central1 |
● | ● | ● | ● | ● | ● | ||
Las Vegas | us-west4 |
● | ● | ● | ● | ||||
Los Angeles | us-west2 |
● | ● | ● | ● | ||||
Montréal | northamerica-northeast1 |
● | ● | ● | ● | ● | ● | ||
Northern Virginia | us-east4 |
● | ● | ● | ● | ● | ● | ||
Oregon | us-west1 |
● | ● | ● | ● | ● | |||
Salt Lake City | us-west3 |
● | ● | ● | |||||
São Paulo | southamerica-east1 |
● | ● | ● | ● | ||||
Santiago | southamerica-west1 |
● | ● | ||||||
South Carolina | us-east1 |
● | ● | ● | ● | ● | |||
Toronto | northamerica-northeast2 |
● | ● | ● | |||||
Europe | |||||||||
Belgium | europe-west1 |
● | ● | ● | ● | ● | ● | ||
Berlin | europe-west10 |
● | ● | ||||||
Finland | europe-north1 |
● | ● | ● | |||||
Frankfurt | europe-west3 |
● | ● | ● | ● | ● | ● | ||
London | europe-west2 |
● | ● | ● | ● | ● | ● | ||
Madrid | europe-southwest1 |
● | ● | ||||||
Milan | europe-west8 |
● | ● | ||||||
Netherlands | europe-west4 |
● | ● | ● | ● | ● | ● | ||
Paris | europe-west9 |
● | ● | ||||||
Turin | europe-west12 |
● | |||||||
Warsaw | europe-central2 |
● | ● | ||||||
Zürich | europe-west6 |
● | ● | ● | ● | ● | ● | ||
Asia Pacific | |||||||||
Delhi | asia-south2 |
● | ● | ||||||
Hong Kong | asia-east2 |
● | ● | ● | ● | ● | ● | ||
Jakarta | asia-southeast2 |
● | ● | ● | |||||
Melbourne | australia-southeast2 |
● | ● | ||||||
Mumbai | asia-south1 |
● | ● | ● | ● | ● | |||
Osaka | asia-northeast2 |
● | ● | ● | |||||
Seoul | asia-northeast3 |
● | ● | ● | ● | ● | ● | ||
Singapore | asia-southeast1 |
● | ● | ● | ● | ● | ● | ||
Sydney | australia-southeast1 |
● | ● | ● | ● | ● | ● | ||
Taiwan | asia-east1 |
● | ● | ● | ● | ● | ● | ||
Tokyo | asia-northeast1 |
● | ● | ● | ● | ● | ● | ||
Middle East | |||||||||
Dammam | me-central2 |
● | |||||||
Doha | me-central1 |
● | |||||||
Tel Aviv | me-west1 |
● | ● | ||||||
Africa | |||||||||
Johannesburg | africa-south1 |
● | ● |
Multi-regional locations
Region description | Region name | Imported models |
Built-in model training |
DNN/Autoencoder/ Boosted Tree/ Wide-and-Deep models training |
AutoML model training |
Hyperparameter tuning |
Vertex AI Model Registry integration |
---|---|---|---|---|---|---|---|
Data centers within member states of the European Union1 | EU |
● | ● | ● | ● | ● | ● |
Data centers in the United States | US |
● | ● | ● | ● | ● | ● |
1 Data located in the EU
multi-region is not
stored in the europe-west2
(London) or europe-west6
(Zürich) data
centers.
Vertex AI Model Registry integration is supported only for single region integrations. If you
send a multi-region BigQuery ML model to the Model Registry,
then it is converted to a regional model in Vertex AI.
A BigQuery ML multi-region US model is synced to Vertex AI
us-central1
and a BigQuery ML multi-region EU model is synced to
Vertex AI europe-west4
. For single region models, there are
no changes.
BigQuery SQL translator locations
When migrating data from your legacy data warehouse into BigQuery, you can use several SQL translators to translate your SQL queries into GoogleSQL or other supported SQL dialects. These include the interactive SQL translator, the SQL translation API, and the batch SQL translator.
The BigQuery SQL translators are available in the following processing locations:
Region description | Region name | Details | |
---|---|---|---|
Asia Pacific | |||
Tokyo | asia-northeast1 |
||
Mumbai | asia-south1 |
||
Singapore | asia-southeast1 |
||
Sydney | australia-southeast1 |
||
Europe | |||
EU multi-region | eu |
||
Warsaw | europe-central2 |
||
Finland | europe-north1 |
Low CO2 | |
Madrid | europe-southwest1 |
Low CO2 | |
Belgium | europe-west1 |
Low CO2 | |
London | europe-west2 |
Low CO2 | |
Frankfurt | europe-west3 |
Low CO2 | |
Netherlands | europe-west4 |
Low CO2 | |
Zürich | europe-west6 |
Low CO2 | |
Paris | europe-west9 |
Low CO2 | |
Turin | europe-west12 |
||
Americas | |||
Québec | northamerica-northeast1 |
Low CO2 | |
São Paulo | southamerica-east1 |
Low CO2 | |
US multi-region | us |
||
Iowa | us-central1 |
Low CO2 | |
South Carolina | us-east1 |
||
Northern Virginia | us-east4 |
||
Columbus, Ohio | us-east5 |
||
Dallas | us-south1 |
Low CO2 | |
Oregon | us-west1 |
Low CO2 | |
Los Angeles | us-west2 |
||
Salt Lake City | us-west3 |
BigQuery partition and cluster recommender
The BigQuery partitioning and clustering recommender generates partition or cluster recommendations to optimize your BigQuery tables.
The partitioning and clustering recommender is available in the following processing locations:
Region description | Region name | Details | |
---|---|---|---|
Asia Pacific | |||
Delhi | asia-south2 |
||
Hong Kong | asia-east2 |
||
Jakarta | asia-southeast2 |
||
Mumbai | asia-south1 |
||
Osaka | asia-northeast2 |
||
Seoul | asia-northeast3 |
||
Singapore | asia-southeast1 |
||
Sydney | australia-southeast1 |
||
Taiwan | asia-east1 |
||
Tokyo | asia-northeast1 |
||
Europe | |||
Belgium | europe-west1 |
Low CO2 | |
Berlin | europe-west10 |
Low CO2 | |
EU multi-region | eu |
||
Frankfurt | europe-west3 |
Low CO2 | |
London | europe-west2 |
Low CO2 | |
Netherlands | europe-west4 |
Low CO2 | |
Zürich | europe-west6 |
Low CO2 | |
Americas | |||
Iowa | us-central1 |
Low CO2 | |
Las Vegas | us-west4 |
||
Los Angeles | us-west2 |
||
Montréal | northamerica-northeast1 |
Low CO2 | |
Northern Virginia | us-east4 |
||
Oregon | us-west1 |
Low CO2 | |
Salt Lake City | us-west3 |
||
São Paulo | southamerica-east1 |
Low CO2 | |
Toronto | northamerica-northeast2 |
Low CO2 | |
US multi-region | us |
Specify locations
When loading data, querying data, or exporting data, BigQuery
determines the location to run the job based on the datasets referenced in
the request. For example, if a query references a table in a dataset stored
in the asia-northeast1
region, the query job will run in that region.
If a query does not reference any tables or other resources contained within
datasets, and no destination table is provided, the query job will run in the
US
multi-region. To ensure that BigQuery queries are stored in
a specific region or multi-region, specify the location with the job request to
route the query accordingly when using the global BigQuery
endpoint. If you don't specify the location, queries may be temporarily stored
in BigQuery router logs when the query is used for determining
the processing location in BigQuery.
If the project has a
capacity-based reservation in a region other than the US
and the query does
not reference any tables or other resources contained within datasets, then you
must explicitly specify the location of the capacity-based reservation when
submitting the job. Capacity-based commitments are tied to a location, such as
US
or EU
. If you run a job outside the location of your capacity, pricing
for that job automatically shifts to on-demand pricing.
You can specify the location to run a job explicitly in the following ways:
- When you query data using the Google Cloud console in the query editor, click More > Query settings, expand Advanced options, and then select your Data location.
- When you use the bq command-line tool, supply the
--location
global flag and set the value to your location. - When you use the API, specify your region in the
location
property in thejobReference
section of the job resource.
BigQuery returns an error if the specified location does not match the location of the datasets in the request. The location of every dataset involved in the request, including those read from and those written to, must match the location of the job as inferred or specified.
Single-region locations don't match multi-region locations, even where the
single-region location is contained within the multi-region location. Therefore,
a query or job will fail if the location includes both a single-region location
and a multi-region location. For example, if a job's location is set to US
,
the job will fail if it references a dataset in us-central1
. Likewise, a job
that references one dataset in US
and another dataset in us-central1
will
fail. This is also true for JOIN
statements with tables in both a region and a
multi-region.
Dynamic queries aren't parsed until they execute, so they can't be used to automatically determine the region of a query.
Locations, reservations, and jobs
Capacity commitments are a regional resource. When you buy slots, those slots
are limited to a specific region or multi-region. If your only capacity
commitment is in the EU
then you can't create a reservation in the US
. When
you create a reservation, you specify a location (region) and a number of slots.
Those slots are pulled from your capacity commitment in that region.
Likewise, when you run a job in a region, it only uses a reservation if the
location of the job matches the location of a reservation. For example, if you
assign a reservation to a project in the EU
and run a query in that project
on a dataset located in the US
, then that query is not run on your EU
reservation. In the absence of any US
reservation, the job is run as
on-demand.
Location considerations
When you choose a location for your data, consider the following:
Cloud Storage
You can interact with Cloud Storage data using BigQuery in the following ways:
- Query Cloud Storage data using BigLake or non-BigLake external tables
- Load Cloud Storage data into BigQuery
- Export data from BigQuery into Cloud Storage
Query Cloud Storage data
When you query data in Cloud Storage by using a BigLake or a non-BigLake external table, the data you query must be colocated with your BigQuery dataset. For example:
Single region bucket: If your BigQuery dataset is in the Warsaw (
europe-central2
) region, the corresponding Cloud Storage bucket must also be in the Warsaw region, or any Cloud Storage dual-region that includes Warsaw. If your BigQuery dataset is in theUS
multi-region, then Cloud Storage bucket can be in theUS
multi-region, the Iowa (us-central1
) single region, or any dual-region that includes Iowa. Queries from any other single region fails, even if the bucket is in a location that is contained within the multi-region of the dataset. For example, if the external tables are in theUS
multi-region and the Cloud Storage bucket is in Oregon (us-west1
), the job fails.If your BigQuery dataset is in the
EU
multi-region, then Cloud Storage bucket can be in theEU
multi-region, the Belgium (europe-west1
) single region, or any dual-region that includes Belgium. Queries from any other single region fails, even if the bucket is in a location that is contained within the multi-region of the dataset. For example, if the external tables are in theEU
multi-region and the Cloud Storage bucket is in Warsaw (europe-central2
), the job fails.Dual-region bucket: If your BigQuery dataset is in the Tokyo (
asia-northeast1
) region, the corresponding Cloud Storage bucket must be in the Tokyo region, or in a dual-region that includes Tokyo, like theASIA1
dual-region.If the Cloud Storage bucket is in the
NAM4
dual-region or any dual-region that includes the Iowa(us-central1
) region, the corresponding BigQuery dataset can be in theUS
multi-region or in the Iowa(us-central1
).If Cloud Storage bucket is in the
EUR4
dual-region or any dual-region that includes the Belgium(europe-west1
) region, the corresponding BigQuery dataset can be in theEU
multi-region or in the Belgium(europe-west1
).Multi-region bucket: Using multi-region dataset locations with multi-region Cloud Storage buckets is not recommended for external tables, because external query performance depends on minimal latency and optimal network bandwidth.
If your BigQuery dataset is in the
US
multi-region, the corresponding Cloud Storage bucket must be in theUS
multi-region, in a dual-region that includes Iowa (us-central1
), like theNAM4
dual-region, or in a custom dual-region that includes Iowa (us-central1
).If your BigQuery dataset is in the
EU
multi-region, the corresponding Cloud Storage bucket must be in theEU
multi-region, in a dual-region that includes Belgium (europe-west1
), like theEUR4
dual-region, or in a custom dual-region that includes Belgium.
For more information about supported Cloud Storage locations, see Bucket locations in the Cloud Storage documentation.
Load data from Cloud Storage
When you load data from Cloud Storage, the data you load must be colocated with your BigQuery dataset.
You can load data from a Cloud Storage bucket located in any location if your BigQuery dataset is located in the
US
multi-region.- Multi-region bucket: If the
Cloud Storage bucket that you want to load from is located in a multi-region bucket, then your
BigQuery dataset can be in the same multi-region bucket or any single region that is included in the same multi-region bucket.
For example, if the Cloud Storage bucket is in the
EU
region, then your BigQuery dataset can be in theEU
multi-region or any single region in theEU
. Dual-region bucket: If the Cloud Storage bucket that you want to load from is located in a dual-region bucket, then your BigQuery dataset can be located in regions that are included in the dual-region bucket, or in a multi-region that includes the dual-region. For example, if your Cloud Storage bucket is located in the
EUR4
region, then your BigQuery dataset can be located in either the Finland (europe-north1
) single-region, the Netherlands (europe-west4
) single-region, or theEU
multi-region.Single region bucket: If your Cloud Storage bucket that you want to load from is in a single-region, your BigQuery dataset can be in the same single-region, or in the multi-region that includes the single-region. For example, if you Cloud Storage bucket is in the Finland (
europe-north1
) region, your BigQuery dataset can be in the Finland or theEU
multi-region.One exception is that if your BigQuery dataset is located in the
asia-northeast1
region, then your Cloud Storage bucket can be located in theEU
multi-region.
For more information, see Batch loading data.
Export data into Cloud Storage
Colocate your Cloud Storage buckets for exporting data:- If your BigQuery dataset is in the
EU
multi-region, the Cloud Storage bucket containing the data that you export must be in the same multi-region or in a location that is contained within the multi-region. For example, if your BigQuery dataset is in theEU
multi-region, the Cloud Storage bucket can be located in theeurope-west1
Belgium region, which is within the EU.If your dataset is in the
US
multi-region, you can export data into a Cloud Storage bucket in any location. - If your dataset is in a region, your Cloud Storage bucket must be in the same region. For
example, if your dataset is in the
asia-northeast1
Tokyo region, your Cloud Storage bucket cannot be in theASIA
multi-region.
For more information, see Exporting table data.
Bigtable
You must consider location when querying data from Bigtable or exporting data to Bigtable.
Query Bigtable data
When you query data in Bigtable through a BigQuery external table, your Bigtable instance must be in the same location as your BigQuery dataset:
- Single region: If your BigQuery dataset is in the Belgium
(
europe-west1
) regional location, the corresponding Bigtable instance must be in the Belgium region. - Multi-region: Because external query performance depends on minimal latency and optimal network bandwidth, using multi-region dataset locations is not recommended for external tables on Bigtable.
For more information about supported Bigtable locations, see Bigtable locations.
Export data to Bigtable
- If your BigQuery dataset is in a multi-region, your
Bigtable app profile
must be configured to route data to a Bigtable cluster within that multi-region.
For example, if your BigQuery dataset is in the
US
multi-region, the Bigtable cluster can be located in theus-west1
(Oregon) region, which is within the United States. - If your BigQuery dataset is in a single region, your Bigtable app profile
must be configured to route data to a Bigtable cluster in
the same region. For example, if your BigQuery dataset is in the
asia-northeast1
(Tokyo) region, your Bigtable cluster must also be in theasia-northeast1
(Tokyo) region.
Google Drive
Location considerations do not apply to Google Drive external data sources.
Cloud SQL
When you query data in Cloud SQL through a BigQuery federated query, your Cloud SQL instance must be in the same location as your BigQuery dataset.
- Single region: If your BigQuery dataset is in the Belgium (
europe-west1
) regional location, the corresponding Cloud SQL instance must be in the Belgium region. - Multi-region: If your BigQuery dataset is in the
US
multi-region, the corresponding Cloud SQL instance must be in a single region in the US geographic area.
For more information about supported Cloud SQL locations, see Cloud SQL locations.
Spanner
When you query data in Spanner through a BigQuery federated query, your Spanner instance must be in the same location as your BigQuery dataset.
- Single region: If your BigQuery dataset is in the Belgium
(
europe-west1
) regional location, the corresponding Spanner instance must be in the Belgium region. - Multi-region: If your BigQuery dataset is in the
US
multi-region, the corresponding Spanner instance must be in a single region in the US geographic area.
For more information about supported Spanner locations, see Spanner locations.
Analysis tools
Colocate your BigQuery dataset with your analysis tools:- Dataproc: When you query BigQuery datasets using a BigQuery connector, your BigQuery dataset should be colocated with your Dataproc cluster. Dataproc is supported in all Compute Engine locations.
- Vertex AI Workbench: When you query BigQuery datasets using Jupyter notebooks in Vertex AI Workbench, your BigQuery dataset should be colocated with your Vertex AI Workbench instance. View the supported Vertex AI Workbench locations.
Data management plans
Develop a data management plan:- If you choose a regional storage resource such as a BigQuery dataset or a Cloud Storage bucket, develop a plan for geographically managing your data.
Restrict locations
You can restrict the locations in which your datasets can be created by using the Organization Policy Service. For more information, see Restricting resource locations and Resource locations supported services.
Dataset security
To control access to datasets in BigQuery, see Controlling access to datasets. For information about data encryption, see Encryption at rest.
What's next
- Learn how to create datasets.
- Learn about loading data into BigQuery.
- Learn about BigQuery pricing.
- View all the Google Cloud services available in locations worldwide.
- Explore additional location-based concepts, such as zones, that apply to other Google Cloud services.