Google Cloud Spanner

As services expand across regions, a single-region relational database starts to show latency and capacity limits. Moving fully to NoSQL would also mean redesigning established SQL, schema, and transaction assumptions.

As services expanded to serve users across continents, teams hit the limits of single-region relational databases. The common workarounds each had painful trade-offs. Read replicas in other regions gave geographic distribution but introduced eventual consistency — a user in Tokyo could read stale data seconds after a write in Virginia. Manual sharding split the data across databases, but cross-shard transactions became impossible or required fragile two-phase commit protocols that slowed everything down. Some teams moved to NoSQL for horizontal scale, only to lose the SQL and transactional guarantees their business logic depended on. Spanner emerged from Google's internal need to solve this exact problem at global scale: preserve relational semantics and strong consistency while distributing data across regions.

Spanner distributes table data across many nodes and coordinates writes across regional replicas before committing them. The key to global strong consistency is synchronized clocks: every Spanner node has access to TrueTime, a clock service with a bounded uncertainty interval. When a transaction commits, the node stamps it with the current time and then waits just long enough for the uncertainty window to pass. After that wait, every other node in the world knows this timestamp is in the past, so they can order transactions consistently without blocking on a network round-trip to a central coordinator. Applications talk to a global SQL endpoint, and this clock-based ordering happens behind the scenes — which is why Spanner can offer strong consistency globally without the latency penalty traditional distributed locking would impose.

Spanner and Cloud SQL are both relational databases, but Cloud SQL stays close to the familiar single-instance model while Spanner is designed around distributed consensus and horizontal scale. If familiar OLTP operations are enough, Cloud SQL fits; if you need global scale with strong consistency, Spanner fits.

Well suited to global account systems, order systems, and financial workflows that need consistent relational data across regions. It is often overkill for single-region apps or cache-heavy workloads.