distributed SQL

CockroachDB

CockroachDB is a distributed SQL database built for survivability. This profile covers what it does, how it is priced, and where it stops being the right choice.

What the product actually does

CockroachDB stores each range of keys on multiple nodes and uses Raft to keep them consistent. A node or an entire region can disappear and the cluster continues, with the trade being that every write must reach a quorum before it commits.

It speaks PostgreSQL's wire protocol, which means existing drivers and most existing SQL work unchanged. That compatibility is the reason teams consider it: the migration is closer to a connection-string change than a rewrite, at least at the start.

How pricing works once you are inside

The self-hosted product is free to run and costs engineering time. The cloud product prices on vCPU hours and storage, with the vCPU meter being the one that decides the bill because a distributed cluster needs a minimum number of nodes to be useful.

The multi-region configuration is the pricing decision that matters. Each additional region multiplies the write latency budget and the node count, and a three-region cluster costs roughly three times a single-region one for the same data.

Where it breaks down

Latency. A write that must reach a quorum across regions is slower than a single-node commit, and applications with chatty write patterns feel it. The database is built for correctness under failure, not for minimum latency.

Operational complexity is real. Running it yourself means understanding range rebalancing, lease preferences and clock skew. The managed product hides most of that and charges accordingly.

What switching costs

Moderate. SQL and drivers port; the assumptions do not. A schema tuned for a single Postgres instance will need index and partitioning work to perform on a distributed cluster.

Sources

CockroachDB public documentation and pricing page, read October 2026.