Cloud Spanner

What is Cloud Spanner?

Cloud Spanner is Google’s globally-distributed, horizontally-scalable relational database that provides strong consistency and SQL at massive scale — combining properties that were long thought mutually exclusive. Traditionally, you scaled a relational database up (a bigger single machine) until you hit a ceiling, and to scale out you moved to a NoSQL system and gave up strong consistency and/or SQL joins. Spanner breaks that tradeoff: it scales out across many machines and even across regions and continents, while still offering ACID transactions, strong consistency, and relational SQL. It powers Google’s own most demanding services and is offered to GCP customers for workloads that genuinely need global scale without abandoning relational guarantees.

Why it’s remarkable — TrueTime and the CAP conversation

Spanner’s headline achievement is externally-consistent, globally-distributed transactions, and the enabling technology is TrueTime — Google’s use of GPS and atomic clocks in its datacenters to give servers a tightly-bounded, globally-synchronized notion of time. With TrueTime, Spanner can order transactions consistently across the planet, delivering strong consistency for distributed transactions that ordinary distributed databases can’t guarantee without crippling coordination. This is why Spanner is often discussed in the context of the CAP theorem: it’s frequently described as an “effectively CA” (or CP with extremely high availability) system — it doesn’t literally repeal CAP (during a true network partition it favors consistency), but Google’s dedicated, redundant network makes partitions rare enough that Spanner achieves both very high availability and strong consistency in practice, which is genuinely unusual. The practical upshot for engineers: you can build a globally-scaled application with a relational model, real transactions, and strong consistency, instead of contorting your data into an eventually-consistent NoSQL design to get scale.

When it’s worth it — and when it’s overkill

The honest guidance is crucial because Spanner is powerful and expensive, and it’s frequently over-reached-for. Spanner earns its cost when you genuinely need global scale, horizontal write scaling, and high availability with strong relational consistency simultaneously — the intersection that nothing else fills well (global financial systems, massive multi-region transactional platforms). For the vast majority of applications, that intersection is not required: a single-region managed relational database like Cloud SQL (or Amazon RDS) handles typical transactional workloads at far lower cost and complexity, and you should reach for it by default. Using Spanner for a workload a Cloud SQL instance would serve is a classic case of paying a large premium for scale and global consistency you don’t use. Other realities: Spanner has its own data-modeling considerations (schema and primary-key design matter for how data is distributed — poor key choice creates hotspots, echoing the partition-key discipline of other distributed databases), it isn’t a drop-in for arbitrary Postgres/MySQL apps (though it offers a PostgreSQL-compatible interface), and its pricing (compute + storage, with a minimum footprint) makes small deployments disproportionately costly. The mistakes: adopting Spanner when a single-region relational database suffices (overpaying for unused scale), and neglecting key/schema design so the distributed system develops hotspots.

What people get wrong

• Using it where Cloud SQL fits — Spanner’s global scale and distributed strong consistency are expensive; most workloads are served far more cheaply by a single-region managed relational database.
• Poor key/schema design: like any distributed database, primary-key choice determines data distribution — bad keys create hotspots that undermine Spanner’s scaling.
• Assuming it repeals CAP — Spanner favors consistency during true partitions; its “have it all” reputation rests on Google’s network making partitions rare, not on defying the theorem.

Primary source: Cloud Spanner documentation