Distributed SQL is appealing because it offers relational access on top of replicated infrastructure. The mistake is expecting it to behave like ordinary single-node Postgres with extra availability added on top.
It still inherits consensus physics.
The Mental Model That Helps
CockroachDB is easier to reason about when you start from Raft and quorum, not from SQL syntax. A write usually has to reach a replica majority before it is durable. If replicas are geographically far apart, write latency reflects that distance.
A simplified picture is:
- one leaseholder receives the write
- followers replicate the log entry
- quorum acknowledges
- the write commits
That is why topology matters so much. The database is not being "slow for no reason." It is doing coordination work.
Why This Shows Up in Production
Once you understand the consensus path, several behaviors become less surprising:
- cross-region writes cost more latency
- hotspot ranges can overload a leaseholder
- node failure recovery is about quorum, not just process restart
- read and write locality decisions affect user experience
Distributed SQL buys strong consistency and operational resilience, but it does not repeal the speed-of-light problem.
Better Rule
Use CockroachDB when the availability and distribution model justify the consensus cost. If the workload is mostly single-region and latency-sensitive, a well-operated Postgres deployment may still be the better engineering choice.
Further Reading