Google Cloud Spanner Cost Optimization: Control Your Globally Distributed Database Spend

Google Cloud Spanner delivers globally distributed, strongly consistent relational databases with horizontal scalability, but costs accumulate quickly across compute capacity, storage volumes, multi-region replication, and supporting services.

Database design fundamentally determines cost efficiency. Poorly designed primary keys create hotspots concentrating traffic on single servers while others sit idle. Transaction patterns with excessive locking waste processing capacity on contention management. Queries requiring full table scans consume substantial compute versus indexed reads accessing specific rows.

This guide addresses practical Spanner cost optimization across capacity provisioning, hotspot elimination, transaction efficiency, query optimization, analytical workload management, topology selection, storage management, and pricing optimization.

How Spanner Pricing Works

Spanner pricing combines compute capacity charges with storage, backup, and network costs. Understanding component pricing guides optimization priorities.

Compute capacity charges for processing units (PUs) or nodes handling transactions and queries. One node equals 1000 PUs. Pricing varies by Spanner edition and configuration. Standard edition starts at $0.030 per 100 PUs per hour per replica, Enterprise at $0.041, and Enterprise Plus at $0.057.

Spanner editions tier capabilities and pricing. Standard edition provides core Spanner capabilities for regional configurations. Enterprise adds advanced capabilities such as multi-model and search functionality, while Enterprise Plus supports the most demanding workloads, including multi-region configurations and higher availability. Organizations should evaluate whether higher-tier capabilities justify the additional cost.

Storage charges separately based on storage type and replica count. SSD storage starts at $0.10/GB/month per replica, while HDD storage starts at $0.02/GB/month per replica.

Backups charge for retained backup volumes: $0.10/GB/month for regional configurations and $0.30/GB/month for dual-region and multi-region configurations. Backup retention policies accumulate costs proportional to backup frequency and retention periods.

Replication increases costs as additional replicas and regions are added. Regional configurations include three replicas, dual-region configurations include six, and multi-region configurations include five or more depending on the topology. Multi-region configurations therefore carry higher compute, storage, and inter-region replication costs than regional deployments.

Data Boost provides isolated compute for analytical queries without impacting transactional workload performance. Data Boost charges based on query processing consumption rather than provisioned capacity, enabling cost-effective separation of OLTP and OLAP workloads.

Network costs apply for data movement between regions and external egress. Intra-region replication is free, while inter-region replication starts at $0.04/GB. Network egress charges vary by destination.

Start With the Right Amount of Spanner Capacity

Capacity provisioning controls the largest portion of Spanner costs. Right-sizing processing units and leveraging autoscaling reduces unnecessary compute spend.

Use Granular Instance Sizing

Processing units enable granular capacity provisioning versus whole-node increments. Regional instances scale from 100 PUs minimum in 100 PU increments. Organizations needing 300 PUs provision exactly 300 PUs rather than rounding to 1000 PUs (1 node).

Analyzing actual CPU utilization reveals appropriate capacity. Spanner monitoring shows CPU utilization across instance capacity. Instances consistently operating below 40% CPU indicate excess capacity.

Optimize Autoscaling Configuration

Autoscaling adjusts compute capacity dynamically based on CPU utilization. Configuring appropriate minimum and maximum capacity limits prevents under-provisioning and runaway costs.

Monitoring actual utilization patterns reveals appropriate autoscaling thresholds matching workload characteristics.

Fix Hotspots Before Adding More Compute

Data distribution patterns determine processing efficiency. Hotspots concentrate traffic on subset of servers wasting capacity.

Design Primary Keys for Even Distribution

Primary key design determines data distribution. Monotonically increasing keys create write hotspots concentrating all writes on single server.

UUID version 4 provides random distribution avoiding hotspots. Hash-based keys combining business identifiers with hash prefixes similarly distribute load.

Identify and Address Hotspots

Key Visualizer surfaces data distribution patterns revealing hotspots. Analyzing visualizer patterns identifies problematic key designs requiring refactoring.

Reduce Transaction Contention and Write Overhead

Transaction patterns impact compute consumption. Efficient transactions minimize processing overhead and contention.

Read-write transactions hold locks during transaction lifetime. Minimizing transaction scope and duration reduces lock contention. Frequently-updated rows create contention points. Counter sharding splits single counter across multiple rows distributing contention.

Mutations API lets applications buffer inserts, updates, and deletes that Spanner applies atomically at commit time. For large numbers of independent writes that don't require atomic transactions, batch writes can improve throughput.

Make Queries and Indexes Earn Their Compute

Query efficiency and index strategy impact compute consumption. Full table scans consume substantial compute. Query execution plans reveal scan operations.

Indexes accelerate queries but increase write overhead and storage. Index design should balance read performance against write costs. Spanner Index Advisor analyzes workload recommending beneficial indexes.

Keep Analytics From Driving Transactional Capacity

Analytical queries often consume substantial compute scanning large data volumes. Mixing OLTP and OLAP workloads on shared capacity forces over-provisioning to handle analytical spikes.

Use Data Boost for Analytical Queries

Data Boost provides isolated compute for analytical workloads without impacting transactional throughput. Data Boost charges based on query processing consumption rather than shared capacity.

Analytical queries reading millions of rows benefit from Data Boost isolation. Report generation, data exports, and analytical aggregations process large datasets without consuming transactional compute capacity. Applications route analytical queries through Data Boost while transactional queries use base capacity.

Data Boost starts at approximately $0.00117 per serverless processing unit (SPU) per hour. Because capacity is provided on demand rather than provisioned continuously, intermittent analytical workloads may cost less through Data Boost than maintaining permanent capacity to handle analytical spikes.

Optimize Analytical Workload Patterns

Analytical queries should leverage appropriate access patterns. Scanning entire tables remains expensive even on Data Boost. Queries filtering on indexed columns or partitioning by timestamp ranges reduce data volumes processed.

Scheduled batch analytics running during low-traffic periods minimize capacity conflicts when not using Data Boost. Organizations tolerating delayed analytics run batch jobs overnight utilizing spare transactional capacity rather than requiring dedicated analytical capacity.

Match Spanner Topology to Availability Requirements

Topology configuration determines cost through region count and replication patterns. Over-engineered topologies waste substantial costs on unnecessary geographic distribution.

Choose Appropriate Regional Configuration

Regional configurations serve single-region applications at lowest cost. Regional instances provide 99.99% availability within single region. Applications without geographic distribution requirements or serving users in single geographic area benefit from regional deployment.

Dual-region configurations provide higher availability than regional with read replicas in second region. Dual-region suits applications requiring availability beyond single-region SLA but not requiring multi-region write capabilities. Dual-region costs approximately 2x regional configuration.

Multi-region configurations distribute data across 3+ regions providing 99.999% availability and global low-latency reads. Multi-region suits globally-distributed applications requiring write capabilities near users worldwide. Multi-region costs approximately 3-5x regional configuration depending on region count.

Avoid Unnecessary Read Replicas

Read replicas provide additional read capacity and lower read latency in specific regions. Replicas consume compute and storage resources proportional to base instance capacity.

Applications with read-heavy workloads benefit from read replicas distributing read traffic geographically. Global applications serving users worldwide achieve lower latency through regional read replicas. Applications with balanced read-write workloads or serving single-region users may not benefit from replica overhead.

Each read replica effectively doubles capacity costs in that region. Organizations should verify read latency and throughput requirements justify replica costs before provisioning replicas. Monitoring actual read patterns reveals whether replicas deliver proportional value.

Optimize Spanner Storage

Storage management reduces costs through lifecycle policies and data architecture decisions.

Use Tiered Storage for Colder Data

Spanner tiered storage can automatically move less frequently accessed data from SSD to lower-cost HDD storage based on tiering policies. This lets organizations keep historical or infrequently accessed data in Spanner without paying SSD rates for the entire dataset.

Google lists SSD storage starting around $0.10/GB/month/replica and HDD around $0.02/GB/month/replica, making HDD substantially cheaper for colder data. Workloads with large datasets but relatively small hot working sets can reduce storage costs by keeping frequently accessed data on SSD while tiering older or less active data to HDD.

Optimize Data Retention

Spanner charges for all stored data including historical records rarely accessed. Applications retaining years of historical data accumulate substantial storage costs. Data lifecycle policies automatically delete old data no longer required.

Time-to-live (TTL) policies delete rows older than specified ages. Applications retaining 90 days of transaction history configure 90-day TTL automatically purging older data. TTL eliminates manual deletion jobs and prevents unbounded storage growth.

Reduce Backup Retention

Backup costs accumulate based on retention periods and backup frequency. Spanner supports incremental backups, so actual backup storage depends on the amount of changed data as well as backup frequency and retention. Backup policies should align with actual recovery requirements.

Recovery point objectives (RPO) guide backup frequency. Applications requiring 24-hour recovery points need daily backups, not hourly backups. Weekly backups suffice for non-critical development instances. Matching backup frequency to RPO requirements reduces backup storage costs.

Backup retention beyond recovery requirements wastes storage spend. Regulatory compliance may require long retention periods, but operational recovery typically requires only recent backups. Organizations can differentiate operational backups (7-30 days) from compliance backups (annual snapshots) reducing operational backup storage.

Optimize Index Storage

Indexes consume storage proportional to indexed column data volumes. Composite indexes store multiple column values multiplying storage costs. Reviewing index usage identifies unnecessary indexes consuming storage without delivering value.

Removing unused indexes immediately reduces storage costs and write overhead. Applications evolve over time; indexes created for queries no longer issued waste resources. Periodic index audits identify removal candidates.

Pay Less for the Capacity You Need

Pricing model optimization and commitment purchasing reduce per-unit costs for predictable workloads.

Choose Appropriate Edition

Standard edition provides core Spanner functionality for regional configurations at the lowest edition price. Enterprise adds multi-model and advanced search capabilities, while Enterprise Plus supports demanding workloads requiring features such as multi-region configurations and the highest availability levels. Organizations should choose the lowest edition that meets their workload requirements.

Use Committed Use Discounts

Committed use discounts reduce compute costs for predictable baseline usage. One-year commitments provide a 20% discount; three-year commitments provide a 40% discount versus on-demand pricing.

Commitments cover baseline compute capacity. Organizations consistently running 500 PUs benefit from commitment coverage saving 20-40% on baseline capacity. Variable capacity above baseline continues paying on-demand rates.

Commitment risk centers on workload stability. Committing to capacity subsequently unused wastes money on unused commitments. Conservative commitment sizing covering 60-70% of typical capacity minimizes risk while capturing substantial discounts.

How nOps Helps Optimize Spanner Costs

Fully optimizing Spanner spend means understanding how compute capacity, instance configuration, storage, replication, and workload patterns contribute to total cost across the broader cloud environment.

That’s where nOps comes in: helping FinOps teams understand, allocate, and optimize Spanner costs alongside the rest of their GCP, AWS, Azure, AI, and SaaS spend.

Unified visibility: Get all of your spending from GCP, AWS, Azure, AI, and SaaS in one place, with cost allocation by application, customer, team, or business unit to understand what is driving spend and where optimization will have the greatest impact.
Commitment Management: Automatically maximize discounts and minimize commitment risk across eligible cloud infrastructure supporting your Spanner workloads. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.

We’ve talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to quantify exactly how much more you could save across the infrastructure supporting Spanner and the rest of your cloud environment.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2’s Cloud Cost Management category.

Demo