Spanner

Exam guide§2.2

Globally distributed relational DB with horizontal scaling AND strong external consistency, backed by TrueTime. Expensive, always-on (no scale-to-zero), 99.999% multi-region SLA. Pick it for relational data that must scale globally with strong consistency - user metadata, financial, AdTech, MarTech.

⚠GotchaSpanner never scales to zero

Spanner bills for provisioned capacity (nodes) even when idle. If the question stresses a small, spiky, or cost-sensitive workload, Spanner is the wrong answer - lean Cloud SQL.

Best of both worlds

When Cloud SQL cannot fit your requirements because you need horizontal scalability, consider Spanner. It was built for the cloud specifically to combine the benefits of a relational structure with non-relational horizontal scale: petabytes of capacity, transactional consistency at global scale, schemas, SQL, and automatic synchronous replication for high availability. Typical use cases are financial and inventory applications - workloads traditionally served by relational database technology.

Spanner combines relational traits (schema, SQL, strong consistency) with non-relational traits (high availability, horizontal scalability, configurable replication) - a relational DB fails over rather than staying highly available and scales vertically, while a non-relational DB gives up schema, SQL, and strong consistency.

Spanner takes the relational half (schema, SQL, strong consistency) and the non-relational half (high availability, horizontal scalability, configurable replication) - which is what makes it fit mission-critical transaction and inventory systems in financial services and retail.

Architecture

A Spanner instance replicates every table across N zones (here 3), which can sit in one region or span several. A write (Update) propagates synchronously to all zones over Google’s global fiber network, and TrueTime atomic clocks order the writes - so every zone stays strongly consistent and the instance stays available if a zone fails.

⚠GotchaSynchronous replication is what makes Spanner strongly consistent

A commit is not acknowledged until the write has propagated to all zones, and TrueTime atomic clocks give every write a globally ordered timestamp. That combination - not just "many replicas" - is why reads are strongly consistent no matter which zone serves them.

Choosing Spanner

Any Yes on the left - outgrown a single-instance RDBMS, sharding for throughput, needing transactional consistency, global data with strong consistency, or consolidating databases - points to Spanner. All No, then ask if you still need full relational capability: Yes lands on Cloud SQL, No on a NoSQL service such as Firestore.

Recap

#NumbersSpanner capacity & SLAs

Dimension	Value
Capacity	Petabytes
Consistency	Transactional, at global scale
Multi-regional uptime SLA	99.999%
Regional uptime SLA	99.99%
Use cases	Financial, inventory

SLAs differ by instance type (multi-regional vs regional) - always confirm current numbers in the documentation. To move an existing MySQL workload onto Spanner rather than re-implementing it, follow the MySQL-to-Spanner migration guide in the docs.