TrueTime, External Consistency & ACID at Global Scale
The Classic Tradeoff, Solved
Cloud Spanner is a fully managed, globally distributed relational database combining SQL, ACID transactions, and schemas with the horizontal scalability typically associated with NoSQL. It's the productized version of technology Google originally built and proved internally at massive scale (e.g. for Ads). Historically, achieving strong consistency at global scale was considered extremely difficult — a fundamental tension between consistency and availability/scale across distributed systems.
TrueTime — the Foundational Innovation
TrueTime is a globally synchronized clock API (GPS + atomic clocks across Google's infrastructure) providing tightly bounded time uncertainty. This lets Spanner order distributed transactions consistently across data centers without a single centralized coordinator — the key mechanism enabling Spanner's strongest guarantees.
External Consistency & ACID Across Shards
External consistency (strict serializability) means if transaction A commits before transaction B starts in real time, every observer sees A's effects before B's — the strongest available consistency guarantee. A transaction spanning multiple shards or regions is still fully Atomic, Consistent, Isolated, and Durable — either all its changes commit together or none do, even though the data is physically distributed across many machines. Internally, Paxos-based consensus keeps replicas agreeing on write order even amid node failures.
One Unified Database, Not Several Eventually-Consistent Ones
Rather than stitching together separate regional databases that sync eventually (risking conflicting writes), Spanner provides one logically unified, strongly consistent database that happens to be physically distributed — avoiding the conflict-resolution complexity eventually-consistent multi-region setups introduce.
Keep your own version of these notes — editable, searchable, and organised by your stack.
Start free