Stay organized with collections
Save and categorize content based on your preferences.
This page describes data residency for Spanner.
Spanner meets data residency compliance and regulatory
requirements by letting you to specify the geographic locations (regions) where
Spanner data is stored.
The term your data is equivalent to the meaning of the term
"Customer Data" in the Data Location item in the Google Cloud
General Service Terms.
Data residency commitments
Data residency commitments in Spanner differ for databases
that don't use geo-partitioning versus
databases that do use geo-partitioning.
Databases that don't use geo-partitioning
For databases that don't use geo-partitioning, Spanner provides
data residency commitments at the database level according to the
Google Cloud Terms of Service.
Databases that use geo-partitioning
For databases that use geo-partitioning, Spanner provides data
residency commitments at the placement
level. For each placement, you can select a specific region or multi-region
location as listed on the Google Cloud locations page.
Spanner stores your data at rest only within the selected region
or multi-region with the following limitations:
A small subset of primary keys, indexed column values, and foreign key column
values (for both placement and non-placement tables) are used as
split boundaries, which
might be stored in the default placement.
Statistics and observability information for key ranges used for the
key visualizer, keys
experiencing high lock contention,
and query statistics
are stored in the default placement.
Column-level statistics
used for query optimization are stored in the default placement.
The following are by design:
Placement table primary keys are used for routing traffic and might be stored
in the default placement. If this is a concern, consider using
UUIDs,
or other keys that aren't in scope for data residency.
Interleaved indexes
inherit placement from the parent row. Global indexes (including keys and
storing values) are placed in the default placement.
If you change the placement key for a row, the data move happens
asynchronously. It might take hours to move the row to the new location. Even
after the data is available and served from the new location, deletion of data
from the old location is subject to the Google Cloud data deletion process.
Data residency encryption
By default, Spanner encrypts customer data at rest.
Spanner handles encryption for you without any additional actions
on your part. This option is called Google default encryption. By default,
Google uses encryption keys from the same location as where your data resides.
If you want to control your encryption keys, then you can use
customer-managed encryption keys (CMEKs) in Cloud KMS
with CMEK-integrated services including Spanner. When using CMEK,
you must select keys in the same location as where your data resides. For more
information, see Customer-managed encryption keys (CMEK) overview.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[],[],null,["# Data residency overview\n\nThis page describes data residency for Spanner.\n\nSpanner meets data residency compliance and regulatory\nrequirements by letting you to specify the geographic locations (regions) where\nSpanner data is stored.\n\nThe following definitions apply to this page:\n\n- A *location* is a Google Cloud region or multi-region as listed on the\n [Google Cloud locations page](/about/locations).\n\n- The term *your data* is equivalent to the meaning of the term\n \"Customer Data\" in the *Data Location* item in the Google Cloud\n [General Service Terms](/terms/service-terms).\n\nData residency commitments\n--------------------------\n\nData residency commitments in Spanner differ for databases\nthat don't use [geo-partitioning](/spanner/docs/geo-partitioning) versus\ndatabases that do use geo-partitioning.\n\n### Databases that don't use geo-partitioning\n\nFor databases that don't use geo-partitioning, Spanner provides\ndata residency commitments at the database level according to the\n[Google Cloud Terms of Service](https://cloud.google.com/terms).\n\n### Databases that use geo-partitioning\n\nFor databases that use geo-partitioning, Spanner provides data\nresidency commitments at the [placement](/spanner/docs/create-manage-data-placements)\nlevel. For each placement, you can select a specific region or multi-region\nlocation as listed on the [Google Cloud locations page](/about/locations).\nSpanner stores your data at rest only within the selected region\nor multi-region with the following limitations:\n\n- A small subset of primary keys, indexed column values, and foreign key column values (for both placement and non-placement tables) are used as [split boundaries](/spanner/docs/schema-and-data-model#database-splits), which might be stored in the default placement.\n- Statistics and observability information for key ranges used for the [key visualizer](/spanner/docs/key-visualizer/getting-started), keys experiencing high [lock contention](/spanner/docs/introspection/lock-statistics), and [query statistics](/spanner/docs/introspection/query-statistics) are stored in the default placement.\n- Column-level [statistics](/spanner/docs/query-optimizer/overview#statistics-packages) used for query optimization are stored in the default placement.\n\nThe following are by design:\n\n- Placement table primary keys are used for routing traffic and might be stored in the default placement. If this is a concern, consider using [UUIDs](/spanner/docs/primary-key-default-value#universally_unique_identifier_uuid), or other keys that aren't in scope for data residency.\n- [Interleaved indexes](/spanner/docs/secondary-indexes#indexes_and_interleaving) inherit placement from the parent row. Global indexes (including keys and storing values) are placed in the default placement.\n- [Foreign keys backing indexes](/spanner/docs/foreign-keys/overview#backing-indexes) are placed in the default placement.\n- If you change the placement key for a row, the data move happens asynchronously. It might take hours to move the row to the new location. Even after the data is available and served from the new location, deletion of data from the old location is subject to the [Google Cloud data deletion process](/docs/security/deletion).\n\nData residency encryption\n-------------------------\n\nBy default, Spanner [encrypts customer data at rest](/docs/security/encryption/default-encryption).\nSpanner handles encryption for you without any additional actions\non your part. This option is called *Google default encryption*. By default,\nGoogle uses encryption keys from the same location as where your data resides.\n\nIf you want to control your encryption keys, then you can use\n*customer-managed encryption keys (CMEKs)* in [Cloud KMS](/kms/docs)\nwith CMEK-integrated services including Spanner. When using CMEK,\nyou must select keys in the same location as where your data resides. For more\ninformation, see [Customer-managed encryption keys (CMEK) overview](/spanner/docs/cmek)."]]
