CockroachDB

CockroachDB is a distributed SQL database, PostgreSQL compatible, run as a usage-billed cloud service or self-hosted, for apps that must stay up across regions.

CockroachDB keeps a relational database answering reads and writes when a server, a zone or a whole cloud region fails. Cockroach Labs builds it in New York City. The engine splits tables into ranges, copies each range to several nodes and commits a change once a quorum of copies agrees. Since 15 September 2026, new cloud deployments run on Cockroach Continuum, the operating model the company built on the CockroachDB engine. Applications connect over the PostgreSQL wire protocol, and transactions keep ACID guarantees across any tables and rows, with SELECT FOR UPDATE for row locks. Multi-region tables and list or range partitioning decide where rows live. JSONB columns take GIN indexes, and TSVECTOR columns give ranked full-text search without a separate search engine. Schema changes run as background jobs that never lock the table, and backups with revision history restore a cluster to a chosen timestamp. Change data capture, logical data replication and physical cluster replication move data out to Kafka, to a second active cluster or to a readable standby in another region. The database is built for developers and platform teams whose applications need strong consistency and must stay online across zones or regions. It suits teams that already write PostgreSQL and want SQL that scales out across nodes. Those who want the database run for them choose Continuum, on shared infrastructure in the Standard tier or dedicated infrastructure in Mission Critical. Teams that keep their own servers run it self-hosted under an Enterprise license, and a bring-your-own-cloud option is offered too. Typical jobs include order management, applications serving users in several regions and active-active pairs of clusters. A team running Kafka feeds it from change data capture, so downstream services see each order the moment it commits. Clusters run on AWS, GCP or Azure, and the PostgreSQL drivers and tools a team already uses connect to it as they would to PostgreSQL. When a node or a region drops out, the remaining replicas elect a new leader and the application keeps taking orders.