This article's lead sectionmay be too short to adequately summarize the key points. Please consider expanding the lead to provide an accessible overview of all important aspects of the article.(December 2023)
The relational functionality is built on top of a distributed, transactional, consistent key-value store that can survive a variety of different underlying infrastructure failures, and is wire-compatible with PostgreSQL which means users can take advantage of a wide range of drivers and tools from the extensive PostgreSQL ecosystem. A CockroachDB cluster consists of a number of nodes that can be spread across failure domains such as data centres or public cloud regions. A cluster can be scaled both horizontally[4] (by adding nodes) and vertically (by increasing the resources allocated to the existing nodes). It can provide high levels of resilience and availability and can be run in a variety of environments such as bare metal, VMs, containers and Kubernetes, both in private data centers and in the cloud. CockroachDB gets its name from cockroaches, as they are known for being disaster-resistant.[5]
While at Google, all three had used Google-owned DBMS’s Bigtable and its successor, Spanner.[3] After leaving Google, they wanted to design and build something similar.[8] Spencer Kimball wrote the first iteration of the design in January 2014, and began the open-source project on GitHub in February 2014, allowing outside access and contributions.[9]
Development on GitHub attracted substantial contributions, which earned the project the Open Source Rookie of the Year award by Black Duck Software.[10]
The co-founders supported the project with conferences, networking, meet-ups, and fund-raising financial rounds.
CockroachDB is designed to run in the cloud and has a high fault tolerance. According to popular news outlets, it is described as “almost impossible” to take down.[15][16][13]
CockroachDB has a consistency model that is designed to match as closely as possible to the capabilities of Google Spanner, but without a dependence on specialized hardware for time synchronization. "No stale reads" is the simplest way to describe this consistency model which has deliberately made the trade-off of having non-linearizable transaction histories.[17] Transactions containing overlapping keys are guaranteed to have external consistency. And so, in practice, systems relying on CockroachDB are very unlikely to reproduce consistency issues because nodes with high variations in clock skew can be removed from clusters, applications can rely on external consistency provided by overlapping keys and writing to the same range, and writes propagate changes to followers' timestamp caches.[18]
