🌐Distributed SQL systems

SQL face, distributed guts

These databases shard data across nodes while keeping a familiar SQL dialect. Underneath you get Raft ranges, distributed transactions, clock uncertainty, and shuffle joins, tuning single-node buffer caches is no longer the whole game.

🧭Reference shapes

Teach patterns, not vendor wars.

System	Notable idea
Google Spanner	TrueTime bounds + externally consistent reads, globally ordered commits at latency cost.
CockroachDB	Raft-backed ranges, SERIALIZABLE default, leaseholder routing for keys.
TiDB	MySQL protocol compatibility over a distributed row store, migration ergonomics.

SQL

Same SQL surface, different execution

SELECT region, COUNT(*) AS orders
FROM global_orders
WHERE created_at > now() - interval '7 days'
GROUP BY region;

✓Illustrative result set

region	orders
EU	120000
US	98000

Single-node habits

Random UUID shard keys with no locality, every join becomes a cross-region shuffle.
Treating global secondary indexes as free, they add write amplification on every participating range.
Ignoring clock skew and lease timing when ordering events across regions.

Placement and latency budgets

Model access paths before choosing shard / partition keys; co-locate hot parent-child rows.
Measure cross-region RTT separately from query CPU; document strong vs follower read tiers.
Make writes idempotent for partial failures and retries.

Transactions

Distributed commit paths are slower and flakier than local ACID, prefer locality, sagas, and clear invariants over “just turn on 2PC everywhere.”

Observability

Learn range health, pending intents, and retry rates, dashboards that only show CPU miss the real story.

Consistency tier

Document what each API guarantees: follower reads may be seconds stale; bounded staleness reads cost extra round trips, say it in the runbook, not only in architecture slides.

TL;DR

Distributed SQL (CockroachDB, YugabyteDB, Google Spanner, Vitess, etc.) splits tables across nodes with replication while exposing familiar SQL. Transactions may be limited to a gateway or shard scope, or use expensive global consensus for serializability. Expect higher baseline latency and topology-aware schema (distribution keys) than single-node Postgres, correctness and latency depend on how well data colocates with queries.