Cloud Spanner
Cloud Spanner is Google's globally distributed relational database. It provides full SQL with ACID transactions, horizontal scaling by adding nodes, and strong consistency across regions. Spanner coordinates writes across data centers globally without sacrificing consistency — a combination no other managed database currently matches at its scale.
Workloads That Need Spanner
Spanner is appropriate when you need writes from multiple regions with strong consistency, or SQL and ACID transactions at horizontal write scale that a single primary cannot serve — for example, a Cloud SQL primary still saturated on write CPU after you have tuned queries, added read replicas, scaled up, and considered AlloyDB. High CPU alone is not the signal; the inability of one primary to keep up with writes is. The minimum cost is significant — a single-region Spanner instance costs more than a mid-tier Cloud SQL instance. Spanner is not a Cloud SQL upgrade; it is a different architecture for a specific class of problem.
Instance Configurations
read-write regions + witnessread-only replicaread-only replica- Regional — replicates across three zones in one region
- Dual-region — synchronous replication across two specific regions, protecting against regional failure (requires the Enterprise Plus edition)
- Multi-region — spans several regions for higher availability and geo-distributed reads, also Enterprise Plus only (external consistency is a Spanner-wide guarantee, not unique to multi-region)
Schema Design
Spanner stores rows in primary key order. Sequential primary keys create write hot spots on a single split boundary. Use UUID, reverse-ordered timestamps, or hash-prefixed keys for write-distributed schemas.
Interleaved tables physically co-locate parent and child rows. Reads of a parent and its children become a single range scan. For parent-child relationships accessed together, interleaving is critical for performance.
- Choosing Spanner for workloads Cloud SQL handles comfortably — higher cost and complexity with no benefit.
- Using sequential primary keys that create write hot spots.
- Not interleaving parent-child tables that are always accessed together.
- Provisioning more nodes or processing units than measured load requires — Spanner cost scales linearly with capacity.
- Treating Spanner like a faster Cloud SQL — the same SQL runs, but bad key design and unoptimized queries behave very differently at scale.
- Start with Cloud SQL — migrate to Spanner only when specific limits are measured.
- Start with regional configuration; add regions only when required.
- Use UUID or hash-prefix primary keys for write-distributed schemas.
- Interleave related tables accessed together.
- Use resource-based autoscaling.
Knowledge Check
At what signal should you consider migrating from Cloud SQL to Spanner?
- When the database grows past more than 10 million rows in any single table, regardless of how heavy or light the write load is
- When you simply need to store copies of the data in more than one geographic region
- When Cloud SQL is consistently above 80–90% CPU under write load, or you need horizontal write scaling with strong consistency
- When your application needs consistent sub-millisecond read latency on every query
Why do sequential primary keys cause problems in Spanner?
- Spanner strictly requires every primary key to be a globally unique randomized UUID, rejecting sequential integer keys outright
- Sequential keys grow and exceed the 4 KB row key size limit far faster than randomized keys ever would
- Rows are stored in primary key order — sequential inserts concentrate all writes on one split boundary, creating a hot spot
- Sequential keys prevent Spanner from distributing read traffic evenly across nodes
What is the purpose of interleaved tables in Spanner?
- They let a parent and child table physically share the exact same primary key index structure on disk, saving disk space
- Parent and child rows are physically co-located, turning a read of a parent and its children into a single range scan
- They automatically replicate every write on the parent table over to the child table
- They merge the two tables into a single denormalized materialized view for faster queries
Which Spanner instance configuration replicates synchronously across two specific regions?
- Regional — replicates synchronously across three separate zones within a single region for zone fault tolerance
- Dual-region — synchronous replication across two specific regions, protecting against a full regional failure
- Multi-region — spans several regions globally to deliver the highest consistency guarantees
- Zonal — replicates only to a passive standby within the very same zone
Which workload is a poor fit for Spanner?
- A small application that fits on a mid-sized Cloud SQL instance and has no global write needs — Spanner only adds cost and complexity here
- An application that needs ACID transactions spanning two distinct geographic regions with full strong external consistency guarantees throughout
- A large multi-tenant SaaS platform with demanding horizontal write scaling requirements as it grows
- A financial system that requires a strict global ordering of every transaction worldwide
You got correct