Distributed SQLintermediate
Distributed SQL Overview
What distributed SQL engines provide, the latency they cost, and how to decide whether you need one.
Distributed SQL engines keep SQL, transactions and joins while spreading data across nodes. Data is divided into ranges (CockroachDB) or tablets (YugabyteDB), each replicated by Raft across several nodes.
What you get
- Horizontal write scaling without application-level sharding. Adding nodes adds capacity, and the engine rebalances.
- Survivability by configuration. Losing a node, a rack or a region is handled by the consensus protocol rather than by a failover procedure.
- Serializable transactions across the whole dataset, including across ranges and regions.
- No failover gap. A leader loss triggers a Raft election measured in seconds, with no manual promotion and no split-brain risk.
What it costs
Other costs worth stating plainly:
- Operational complexity. You now operate a distributed system: cluster membership, rebalancing, version upgrades across nodes, and diagnostics that span machines.
- Contention behaves differently. A hot row is now a hot Raft leader, and contention produces transaction retries rather than lock waits. Applications must retry serialization failures.
- Query patterns matter more. A query that touches many ranges fans out; one that touches a single range is fast. This is the same locality concern as sharding, expressed in SQL.
- Ecosystem gaps. PostgreSQL wire compatibility is not PostgreSQL feature parity. Extensions, some data types and some DDL behave differently or are unsupported.
When it is the right choice
- Transactional write volume genuinely exceeds what one primary can absorb, and sharding the application is worse than adopting a distributed engine.
- A regional outage must not take the service down, and the recovery time objective is near zero.
- Data residency requires rows to live in specific regions while remaining part of one logical database.
When it is not
- A single-node engine with a replica would do. This is the common case. PostgreSQL on modern hardware handles far more than most teams assume, and it is dramatically simpler to run. See Choosing a Database.
- The workload is read-heavy. Read replicas solve that without distributed writes.
- Latency budgets are tight and the deployment is multi-region. Consensus latency may exceed the budget outright.
The two engines covered here
See CockroachDB vs YugabyteDB for a criteria-based comparison.