# Overprovisioned Spanner Compute Capacity Without Autoscaling Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-spanner-compute-capacity-without-autoscaling Spanner charges for the compute capacity provisioned on an instance, measured in nodes or processing units, for every hour it exists, regardless of how... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version Spanner charges for the compute capacity provisioned on an instance, measured in nodes or processing units, for every hour it exists, regardless of how much of it queries actually use. PointFive Research Cloud cost research at PointFive GCP service [GCP Spanner](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-spanner) Category [Databases](https://www.pointfive.co/efficiency-hub/service-category/databases) Reference CER-0481 Type Overprovisioned Resource ## Explanation Why the waste happens and who it affects. Instances are commonly sized once for peak traffic, a launch, a load test or a migration, and then left at that size. Workloads with daily or weekly cycles, such as business-hours applications or batch windows, then pay peak capacity around the clock. Teams tend to keep that headroom because under-sizing shows up as latency, while over-sizing only shows up on the bill. Google's guidance positions autoscaling as the fix: it reduces costs by decreasing compute capacity during off-peak hours and avoids over-provisioning, while adding capacity when load or storage grows. Instances that run well below Google's recommended CPU maximums for long periods are the clearest candidates. ## Billing model The pricing dimensions that drive this cost. Compute capacity Billed as node-hours at an hourly rate that varies by edition and region; 1,000 processing units equal one node, and smaller instances are billed proportionally One-hour minimum Any compute capacity you provision is billed for at least one hour, then prorated Replication and read replicas Dual-region and multi-region instances are also charged for cross-region data replication, and optional read-only replicas add their own compute capacity charges Storage limit per node Each node supports up to 10 TiB of data, which sets a floor on how far capacity can be reduced ## How to detect 4 checks to find it in your estate. - Chart CPU utilization by priority and the 24-hour smoothed CPU utilization for each instance over at least a full weekly cycle in the Spanner console or Cloud Monitoring - Compare peaks with Google's recommended maximums: high-priority CPU at or below 65 percent for regional instances and 45 percent per region for dual-region and multi-region instances; instances that stay far below these for most hours are overprovisioned - List instances with a fixed node or processing unit count and no managed autoscaler configuration - Check storage per node against the 10 TiB per node limit to find the lowest capacity the data allows ## How to fix 5 ways to remove the waste. - On Enterprise and Enterprise Plus editions, enable the managed autoscaler with minimum and maximum limits and a high-priority CPU utilization target; Google recommends 65 percent for regional and 45 percent for multi-region instances to leave room for failover - On Standard edition, where the managed autoscaler is not available, use the open source Autoscaler tool or scheduled resizing for predictable cycles - Where autoscaling is not suitable, reduce static capacity to observed need in steps while keeping CPU under the recommended maximums, since scale-down can be limited by storage and database splits - Remember that autoscaling does not fix lock contention or hotspots; investigate those separately instead of adding capacity to mask them - After right-sizing, evaluate Spanner committed use discounts only for the steady baseline capacity ## Documentation Vendor references for pricing and configuration. - [Autoscaling overview docs.cloud.google.com](https://docs.cloud.google.com/spanner/docs/autoscaling-overview) - [Managed autoscaler docs.cloud.google.com](https://docs.cloud.google.com/spanner/docs/managed-autoscaler) - [Compute capacity, nodes and processing units docs.cloud.google.com](https://docs.cloud.google.com/spanner/docs/compute-capacity) - [CPU utilization metrics docs.cloud.google.com](https://docs.cloud.google.com/spanner/docs/cpu-utilization) - [Cloud spanner cloud.google.com](https://cloud.google.com/spanner/pricing) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP Cloud SQL CER-0183 ### [Underutilized Cloud SQL Instance](https://www.pointfive.co/efficiency-hub/inefficiencies/underutilized-cloud-sql-instance) Cloud SQL instances are often over-provisioned or left running despite low utilization. Since billing is based on allocated vCPUs, memory, and storage - not usage - any misalignment between actual workload needs and provisioned capacity... Databases - GCP Cloud SQL CER-0478 ### [Oversized Cloud SQL Storage After Automatic Storage Increase](https://www.pointfive.co/efficiency-hub/inefficiencies/oversized-cloud-sql-storage-after-automatic-storage-increase) Cloud SQL enables automatic storage increase by default. The service checks available storage every 30 seconds and adds capacity when free space drops below a threshold, and by default there is no upper limit. Google documents these... Databases - GCP Bigtable CER-0482 ### [Overprovisioned Bigtable Clusters Without Autoscaling](https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-bigtable-clusters-without-autoscaling) Bigtable compute is billed per provisioned node per hour for every cluster in an instance, whatever the traffic. Google's pricing page states that node charges are for provisioned resources regardless of node usage and apply even if the... Databases --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.