CockroachDB

Best for

• ·Global applications requiring ACID transactions without a single-region primary: no manual failover or region promotion needed
• ·Financial systems requiring serializable isolation across geographically distributed writes with no tolerance for split-brain
• ·Applications subject to data residency regulations: GDPR row-level geo-partitioning pins specific tenants' data to specific regions via PARTITION BY LIST
• ·Horizontal write scaling for relational workloads where PostgreSQL single-primary throughput is the bottleneck
• ·Multi-cloud or hybrid deployments requiring a single SQL interface across regions with automatic range rebalancing

Excels when

• ·Workload is naturally partitioned by a well-distributed key (UUID, hash) that minimizes cross-range transactions
• ·Read traffic can tolerate bounded staleness and use follower reads to avoid Raft round-trips
• ·The application already uses PostgreSQL-compatible SQL and can adopt CockroachDB's dialect differences with minimal query changes
• ·Multi-region operation is a hard requirement and the team has capacity to operate a distributed cluster

Avoid when

• ·Single-region deployment where PostgreSQL provides lower latency, lower cost, and simpler operations without the distributed overhead
• ·Workload is primarily analytical: CockroachDB is an OLTP engine; large aggregation queries cause full-cluster fan-out and should use a dedicated analytics store
• ·Write patterns produce hot ranges (monotonic keys, sequential IDs) and the team cannot change the key generation scheme
• ·Latency SLA is sub-5ms for all write transactions: cross-region Raft commits are incompatible with this requirement

Read scalability

Known failure modes

• ·Cross-range distributed transactions are subject to two-phase commit coordinator failure: if the coordinator dies mid-transaction, the transaction enters a deadlock resolution path that can hold locks for seconds
• ·Clock skew exceeding 500ms causes nodes to self-terminate: CockroachDB requires NTP synchronization across all nodes; cloud environments must be monitored for clock drift
• ·Hot range contention: if all writes target the same key range (e.g., monotonically increasing primary keys), that range's Raft leader becomes a bottleneck
• ·Multi-region transactions spanning three regions require two Raft round trips each: at 80ms inter-region RTT, a simple two-row cross-region transaction takes 200ms+
• ·Scatter queries (queries without a shard key predicate) must be executed on all ranges: can cause fan-out latency spikes proportional to cluster size
• ·Node decommissioning during range rebalancing can cause transient latency increases as Raft leadership elections occur for affected ranges

Bottlenecks

• ·Two-phase commit coordinator for cross-range transactions adds latency proportional to the number of ranges touched and the network RTT between coordinator and range leaders
• ·Hot range contention: a single Raft leader handles all writes to its range; hash-prefix or UUID key design is required to distribute write load
• ·Network round-trip time is the primary latency floor for multi-region transactions: no amount of hardware scaling overcomes WAN latency
• ·Full-table scans in a distributed cluster fan out to all ranges: analytical queries are expensive without range pruning
• ·Raft election during node failure causes a brief write unavailability for affected ranges while a new leader is elected

Degradation patterns

• ·Clock skew approaching 500ms threshold causes proactive node shutdown to preserve consistency: all ranges on the node become unavailable until clock sync is restored
• ·Hot range overload causes queue depth to grow on the range leader; other nodes in the cluster appear healthy while the hot range shows increasing write latency
• ·Cross-region transaction storms during multi-region failover testing cause lock contention as transactions are retried: applications must implement exponential backoff on serialization errors

Common topology roles