Distributed SQL
Preserve relational queries and transactions while distributing storage and execution.
2–5 minute refresher
Coordinator
1 · PREPARE↓2 · COMMIT / ABORT
Inventoryready ✓
Paymentready ✓
Ledgerready ✓
SQL plan over ranges + replicated state + distributed transaction protocol
30second
refresher
refresher
Distributed SQL systems retain relational schemas, query planning, and transactions while partitioning and replicating data across nodes. They coordinate metadata, timestamps, locks or intents, and query fragments.
What problem does it solve?
Teams want horizontal scale and resilience without abandoning joins, constraints, and transactional invariants.
How it works
- Translate SQL into a logical and physical plan.
- Route scans and writes to the ranges that own the data.
- Push computation near storage and exchange only necessary rows.
- Coordinate multi-range writes with timestamps and an atomic commit protocol.
- Replicate each range and recover its authority independently.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Global transactions | Simple cross-row invariants | Coordination and tail latency |
| Locality-aware schema | Fast common operations | More deliberate data modeling |
| Distributed joins | Flexible analytics | Network shuffle and memory pressure |
What happens if?
One participant is slow during commit
The transaction's latency follows the slowest required participant and may leave an ambiguous client result. Deadlines, durable transaction records, recovery, and idempotent retries are necessary.
Where it appears
- Google Spanner
- CockroachDB
- TiDB
- YugabyteDB
Senior interview modeWhy can a normalized schema perform poorly in distributed SQL?Show answer
Frequently joined or transactionally updated rows may land on different ranges, turning local operations into distributed scans, shuffles, and commits. Locality-aware keys or selective denormalization can keep the common path local.