Compute capacity, nodes and processing units

This page describes Spanner compute capacity and the two units of measure used to quantify it: nodes and processing units.

Compute capacity

Compute capacity defines the amount of server and storage resources that are available to the databases in an instance. When you create an instance, you specify its compute capacity as a number of processing units or as a number of nodes, with 1000 processing units being equal to 1 node.

The measurement unit you use does not matter unless you are creating an instance whose compute capacity is smaller than 1000 processing units (1 node); in this case, you must use processing units to specify the compute capacity of the instance.

When you define or change compute capacity on an instance, you specify processing units in multiples of 100 (100, 200, 300 and so on). When the number of processing units reaches 1000, you can specify larger quantities either as multiples of 1000 processing units (1000, 2000, 3000 and so on) or as nodes (1, 2, 3 and so on).

Instances with fewer than 1000 processing units are built for smaller data sizes, queries, and workloads. They have limited compute resources and that might result in non-linear scaling and performance for some workloads, and might experience intermittent increases in latencies.

Data storage limits

Note: Storage usage is calculated in binary gigabytes (GB), where 1 GB is 2³⁰ bytes. This unit of measurement is also known as a gibibyte (GiB). Similarly, 1 TB is 2⁴⁰ bytes, or 1024 GB.

As detailed in Quotas & limits, to provide high availability and low latency when accessing a database, Spanner uses the compute capacity of an instance as a basis for determining storage limits, using the following guidelines:

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

For example, to create an instance for a 300 GB database, you can set its compute capacity to 100 processing units. This amount of compute capacity keeps the instance below the limit until the database grows to more than 1024.0 GB. After the database reaches this size, you need to add another 100 processing units to allow the database to grow. Otherwise, Spanner might reject writes to the database. For more information, see Recommendations for database storage utilization.

Spanner bills for the storage that instances actually utilize, and not their total storage allotment.

Performance

The peak read and write throughput values that a given amount of compute capacity can provide depend on the instance configuration, as well as on schema design and dataset characteristics. For more information, see the Performance overview.

You use instances with fewer than 1000 processing units for smaller data sizes, queries, and workloads. For larger workloads, their limited compute resources might result in non-linear scaling and performance, with intermittent increases in latencies.

Compute capacity and instance configurations

As described in Regional, dual-region, and multi-region configurations, Spanner distributes an instance across zones of one or more regions to provide high performance and high availability. Consequently, Spanner also distributes server resources provided by the instance's compute capacity.

Here is a diagram that illustrates this distribution of server resources.

This diagram depicts two instances that have regional configurations:

• Instance-A shows an instance of 1000 processing units (1 node) with its compute capacity distribution consuming server resources in each of the three zones.
• Instance-B shows an instance of 2000 processing units (2 nodes) with its compute capacity distribution consuming server resources in each of the three zones.

Note the following in this diagram:

• For each instance, Spanner allocates server resources in each zone of the regional configuration. Each per-zone server resource uses the data replica in its zone. For information about data replicas in instance configurations, see Regional, dual-region, and multi-region configurations. For information about how Spanner keeps these data replicas in sync, see Replication.

• The server resources for Instance-A are shown in single boxes, while the resources for Instance-B are shown in boxes subdivided into two parts. This difference illustrates that Spanner allocates server resources differently for different-sized instances:

  • For instances of 1000 processing units (1 node) and smaller, Spanner allocates server resources in a single server task per zone.
  • For instances larger than 1000 processing units (1 node), Spanner allocates server resources in multiple server tasks per zone, with one task for each 1000 processing units. Using multiple server tasks per zone provides better performance and enables Spanner to create database splits and provide even better performance.

Change the compute capacity

After you create an instance, you can increase its compute capacity later. In most cases, requests complete within a few minutes. On rare occasions, a scale up might take up to an hour to complete.

In most cases, you can also decrease compute capacity. There are a few cases where you can't decrease compute capacity:

• Removing compute capacity requires your instance to store more than 10 TB of data per 1000 processing units (1 node).
• Based on your historic usage patterns, Spanner has created a large number of splits for your instance's data, and in some rare cases Spanner wouldn't be able to manage the splits after removing compute capacity.

In the latter case, you might try reducing the compute capacity by progressively smaller amounts until you find the minimum capacity that Spanner needs to manage all of the instance's splits. If the instance no longer requires so many splits due to a change in usage patterns, Spanner might eventually merge some splits together and allow you to try reducing the instance's compute capacity further after a week or two.

When removing compute capacity, monitor your CPU utilization and request latencies in Cloud Monitoring to ensure CPU utilization stays under 65% for regional instances and 45% for each region in multi-region instances. You might experience a temporary increase in request latencies while removing compute capacity.

Spanner doesn't have a suspend mode. Spanner compute capacity is a dedicated resource and, even when you are not running a workload, Spanner frequently performs background work to optimize and protect your data.

You can use the Google Cloud console, Google Cloud CLI, or the Spanner client libraries to change compute capacity. For more information, see Change the compute capacity.

Note: You can change compute capacity in your instance based on the Cloud Monitoring metrics on CPU or storage utilization in conjunction with Cloud Run functions.

Compute capacity versus replicas

If you need to scale up the server and storage resources in your instance, increase the compute capacity of the instance. Note that increasing compute capacity doesn't increase the number of replicas (which are fixed for a given instance configuration), but rather increases the resources each replica has in the instance. Increasing compute capacity gives each replica more CPU and RAM, which increases the replica's throughput (that is, more reads and writes per second can occur).

What's next

• Learn how to Create and manage instances.