CockroachDB
Distributed SQL that survives datacenter loss: Raft ranges, serializable by default.
CockroachDB is a distributed SQL database that shards your tables into ranges of ~512 MiB, each replicated three times via the Raft consensus protocol. It speaks the Postgres wire protocol, offers serializable isolation by default, and keeps working through node loss — while the SQL layer stays familiar: joins, indexes, transactions.
Ranges: the unit of distribution
Tables and indexes split into ordered ranges, each a replicated Raft group with its own LSM (Pebble) store. Ranges split and rebalance automatically.
Serializable by default
Every transaction runs at serializable isolation via timestamp ordering and write intents — no anomaly configuration, no isolation-mode footguns.
Survives failures
Losing one replica of three: zero downtime, zero data loss. Losing a datacenter: configure region-local replicas and survive it too.
Postgres on easy mode
Drivers, ORMs, and most SQL just work against the Postgres wire protocol — with schema changes online and multi-region table locality controls.
Distributed SQL without the distributed-systems degree
A CockroachDB cluster is a key-value map underneath: table data encodes into keys, ordered ranges of keys get replicated via Raft, and the SQL layer on top gives you joins, constraints, and transactions as if it were one Postgres instance.
The transaction story is MVCC with timestamp ordering: readers never block writers, writers detect conflicts at commit, and every commit survives Raft majority agreement before acknowledging — the durability rule databases have used since WAL, now per range.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- serializable, replicated, survives node loss
The commit boundary, distributed
The walkthrough below shows the commit and crash-recovery loop every serious engine implements — the same rule CockroachDB applies per range: a transaction exists once its consensus record is durable, and recovery replays to that point. What is new here is scale: thousands of Raft groups, ranges splitting under load.
Multi-region tables add locality controls: keep a user’s rows in their region, enforce uniqueness globally. The engine handles the placement; you declare the intent.
Diagrams
static storyboard — WebGPU animates when available
A live WebGPU particle field tinted to this exhibit. Plays only with WebGPU and no reduced-motion preference; a static storyboard renders for everyone else.
[caption] Generic WAL/durability timeline — CockroachDB applies the rule per Raft range across thousands of ranges.
Every range replicates its Raft log; a transaction is durable once its record reaches majority agreement. Crash recovery replays to the last committed point.
[caption] Postgres semantics, distributed execution.
A transaction writes through a timestamp-ordered KV layer; each range replicates via Raft before the commit acknowledges; the range LSM (Pebble) stores the data.
| visible after recovery | v2 (balance 250) |
| v1 (100) | dead tuple — reclaimed by VACUUM |
| WAL replay stop point | A’s flushed commit record |
| durability rule | commit waits for WAL flush |
All steps
- Tx A: UPDATE balance 100 → 250 — A new version (v2, xmin = 100) is written and chained; v1 is marked dead-upon-A’s-commit. Nothing in place is overwritten — writers never block readers.
- Reader B (old snapshot) still sees 100 — B’s snapshot was taken before A ran. xmin = 100 is in progress ⇒ v2 is invisible to B; it follows the chain to v1 (100). Repeatable reads in action.
- A commits — WAL flushed first — The commit record is appended and flushed to WAL; only then does the client get acknowledgment. Data pages may not even be written yet.
- Crash after the commit — The process dies before any checkpoint. The WAL is the truth: committed work survives, uncommitted tails are discarded.
- Recovery replays to the commit record — Replay restores v2 (250). A committed transaction cannot be lost — this is the durability half of ACID, paid for at commit latency.
- Reader C (new snapshot) sees 250 — Snapshots taken after the commit see v2; v1 is now a dead tuple that VACUUM will reclaim later.
Transaction visibility, the WAL commit boundary, and crash recovery — PostgreSQL-flavored. Simplified: xmin-only version chains, no xmax/clog details; the durable rule shown here is exact: a transaction exists only once its commit record is flushed to WAL.
Generic MVCC+WAL mechanics; CockroachDB distributes the same rule across Raft groups with timestamp cache conflicts.
[caption] Generic MVCC+WAL mechanics; CockroachDB distributes the same rule across Raft groups with timestamp cache conflicts.
Version visibility, the WAL commit boundary, and recovery replay — the durability rule CockroachDB enforces per Raft range.