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 10 million rows in any single table, no matter how heavy or light the write load on it happens to be
- When you simply need to store copies of the same data in more than one geographic region for reads
- 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 single query it issues
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 integer keys grow and exceed the 8 KiB row key size limit far faster than randomly generated UUID keys ever would in practice
- Rows are stored in primary key order, so sequential inserts concentrate every write on a single split boundary
- Sequential keys stop Spanner from distributing read traffic evenly across the nodes in the instance
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 made to the parent table over into the child table as well, keeping the two in sync
- They merge the parent and the child table into a single denormalized materialized view, so that queries against it run faster
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 named regions, which protects against the failure of a whole region
- Multi-region — spans several regions globally to deliver the highest consistency guarantees
- Zonal — it replicates only to a passive standby instance that sits inside the very same zone
Which workload is a poor fit for Spanner?
- A small application that already fits comfortably on a mid-sized Cloud SQL instance and has no need for globally distributed writes anywhere in it
- 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 keeps growing
- A financial system that requires a strict global ordering of every transaction placed anywhere worldwide
You got correct