Quotas & limits

This page describes production quotas and limits for Cloud Spanner. The difference between a quota and a limit is that a limit cannot be adjusted, whereas you can request a quota increase. Quota and limit may be used interchangeably in Google Cloud Console. If Google Cloud Console indicates edit is not allowed for a quota, it is actually a limit that cannot be adjusted.

The quota and limit values are subject to change.

Checking your quotas

To check the current quotas for resources in your project, use the Google Cloud Console:

Check your quotas

Increasing your quotas

As your use of Cloud Spanner expands over time, your quotas can increase accordingly. If you expect a notable upcoming increase in usage, you should make your request a few days in advance to ensure your quotas are adequately sized.

  1. Go to the Quotas page in the Cloud Console.

    Go to the Quotas page

  2. Select Cloud Spanner API in the Service dropdown list.

    If you do not see Cloud Spanner API, the Cloud Spanner API has not been enabled.

  3. Select the quotas you want to change.

  4. Click Edit Quotas.

  5. Fill in your name, email, and phone number and click Next.

  6. Fill in your quota request and click Submit request.

You will receive a response from the Cloud Spanner team within 48 hours of your request.

Instance limits

Value Limit
Instance ID length 2 to 64 characters

Database limits

Value Limit
Databases per instance
  • For instances of 1 node (1000 processing units) and larger: 100 databases
  • For instances smaller than 1 node: 10 databases per 100 processing units
Database ID length 2 to 30 characters
Storage size1
  • For instances of 1 node (1000 processing units) and larger: 2 TB per node
  • For instances smaller than 1 node: 204.8 GB (≈205 GB) per 100 processing units

Backups are stored separately and do not count towards this limit. For more information, see Storage utilization metrics.

Backup and restore limits

Value Limit
Number of ongoing create backup operations per database 1
Number of ongoing restore database operations per instance (in the instance of the restored database, not the backup) 1
Maximum retention time of backup 1 year (including the extra day in a leap year)

Schema limits

DDL statements

Value Limit
DDL statement size for a single schema change 10 MB
DDL statement size for a database's entire schema, as returned by GetDatabaseDdl 10 MB


Value Limit
Tables per database 5,000
Table name length 1 to 128 characters
Columns per table 1,024
Column name length 1 to 128 characters
Size of data per column 10 MB
Number of columns in a table key


Includes key columns shared with any parent table

Table interleaving depth


A top-level table with child table(s) has depth 1.

A top-level table with grandchild table(s) has depth 2, and so on.

Total size of a table or index key

8 KB

Includes the size of all columns that make up the key


Value Limit
Indexes per database 10,000
Indexes per table 32
Index name length 1 to 128 characters
Number of columns in an index key


The number of indexed columns (except for STORING columns) plus the number of primary key columns in the base table


Value Limit
Views per database 5,000
View name length 1 to 128 characters
Nesting depth


A view that refers to another view has nesting depth 1. A view that refers to another view that refers to yet another view has nesting depth 2, and so on.

Query limits

Value Limit
Columns in a GROUP BY clause 1000
Function calls 1000
Joins 20
Nested function calls 75
Nested GROUP BY clauses 35
Nested subquery expressions 25
Nested subselect statements 60
Parameters 950
Query statement length 1 million characters
STRUCT fields 1000
Subquery expression children 50
Unions in a query 200

Limits for creating, reading, updating, and deleting data

Value Limit
Commit size (including indexes) 100 MB
Concurrent reads per session 100
Mutations per commit (including indexes)2 20,000
Concurrent Partitioned DML statements per database 20,000

Administrative limits

Value Limit
Administrative actions request size3 1 MB
Rate limit for administrative actions4

5 per second per project per user

(averaged over 100 seconds)

Request limits

Value Limit
Request size other than for commits5 10 MB


1. To provide high availability and low latency for accessing a database, Cloud Spanner defines storage limits based on the compute capacity of the instance:

  • For instances smaller than 1 node (1000 processing units), Cloud Spanner allots 204.8 GB (≈205 GB) of data for every 100 processing units in the database.
  • For instances of 1 node and larger, Cloud Spanner allots 2 TB of data for each node.

For example, to create an instance for a 300 GB database, you need to set its compute capacity to 200 processing units. This amount of compute capacity will keep the instance below the limit until the database grows to more than 409.6 GB. After the database reaches this size, you need to add another 100 processing units to allow the database to grow. Otherwise, writes to the database may be rejected. For more information, see Recommendations for database storage utilization.

For a smooth growth experience, add compute capacity before the limit is reached for your database.

2. Insert and update operations count with the multiplicity of the number of columns they affect, and primary key columns are always affected. For example, inserting a new record may count as five mutations, if values are inserted into five columns. Updating three columns in a record may also count as five mutations if the record has two primary key columns. Delete and delete range operations count as one mutation regardless of the number of columns affected. Deleting a row from a parent table that has the ON DELETE CASCADE annotation is also counted as one mutation regardless of the number of interleaved child rows present. The exception to this is if there are secondary indexes defined on rows being deleted, then the changes to the secondary indexes will be counted individually. For example, if a table has 2 secondary indexes, deleting a range of rows in the table will count as 1 mutation for the table, plus 2 mutations for each row that is deleted because the rows in the secondary index might be scattered over the key-space, making it impossible for Cloud Spanner to call a single delete range operation on the secondary indexes. Secondary indexes include the foreign keys backing indexes.

To find the mutation count for a transaction, see Retrieving commit statistics for a transaction.

3. The limit for an administrative action request excludes commits, requests listed in note 5, and schema changes.

4. This rate limit includes all calls to the admin API, which includes calls to poll long-running operations on an instance, database, or backup.

5. This limit includes requests for creating a database, updating a database, reading, streaming reads, executing SQL queries, and executing streaming SQL queries.