Courses › System Design › Key Technologies

Spanner & NewSQL

Globally distributed SQL: Paxos, TrueTime, external consistency and hot-spot-free keys.

Google Cloud Spanner is a globally distributed relational database that offers SQL, ACID transactions and strong consistency while scaling horizontally across regions. It's the best-known example of a NewSQL database; CockroachDB and YugabyteDB follow the same design and are open source. In interviews, it's the answer when you need relational transactions *and* more scale or geographic reach than a single PostgreSQL primary can give.

How it works

  • Tables are split into ranges of rows called splits, distributed across many servers and re-split automatically as data grows.
  • Each split is replicated across zones or regions with Paxos (Raft in CockroachDB). A write commits once a majority of replicas acknowledge it, so losing a zone — or, in multi-region configurations, a region — loses no data.
  • Transactions that touch several splits use two-phase commit across the Paxos groups.
  • TrueTime — GPS and atomic clocks give every server a tightly bounded clock uncertainty. Spanner waits out that uncertainty before committing, which gives transactions a global order (external consistency): if transaction A commits before B starts, B sees A's writes, everywhere.

[!NOTE] CockroachDB without atomic clocks CockroachDB uses hybrid logical clocks instead of TrueTime. It provides serializable transactions, with occasional retries when clock uncertainty creates a conflict.

Schema design matters

  • Avoid monotonically increasing primary keys (auto-increment IDs, timestamps). They send all inserts to the last split and create a hot spot. Use UUIDs, or hash or reverse the key.
  • Interleaved tables (Spanner) store child rows physically next to their parent — e.g. an order's line items with the order — so parent-child reads and transactions stay on one split.
  • Keep transactions small and local where you can: a cross-region transaction pays cross-region latency.

Trade-offs

  • Write latency — every commit needs a quorum round-trip. In a single region that's a few milliseconds; across continents it's 50–100 ms or more.
  • Reads — strong reads may need to check with the leader; stale reads (data up to N seconds old) can be served by any nearby replica and are much faster.
  • Cost and lock-in — Spanner is a premium managed service; CockroachDB is the portable alternative.

When to use it

  • Financial ledgers, inventory and bookings that need strict correctness at a scale beyond one database primary
  • Multi-region applications that need consistent data and to survive a region outage
  • Teams that want SQL and transactions without managing manual sharding

When not to

  • Data that fits comfortably on one PostgreSQL primary with read replicas — simpler and cheaper
  • Workloads that tolerate eventual consistency and need the lowest write latency — Cassandra or DynamoDB
  • Analytics — use a warehouse or ClickHouse

[!INTERVIEW] Global digital wallet "Balances must never go negative, and users transfer money across regions. I'll keep accounts and the ledger in Spanner, so a transfer is one ACID transaction that debits one account and credits another, even if they live on different splits. I'll use UUID account keys to avoid hot spots, and serve the transaction-history screen with stale reads from the nearest replica." See Keeping Money Correct.