CockroachDB review: A scale-out SQL database built for survival

CockroachDB is a distributed SQL database built on top of a transactional and consistent key-value store that can withstand datacenter failures

CockroachDB review: A scale out SQL database built for survival
At a Glance

Until very recently, when you shopped for a database you had to choose: Scalability or consistency? SQL databases such as MySQL guarantee strong consistency, but don’t scale well horizontally. (Manual sharding for scalability is no one’s idea of fun.) NoSQL databases such as MongoDB scale beautifully, but offer only eventual consistency. (“Wait long enough, and you can read the right answer”—which isn’t any way to do financial transactions.)

Google Cloud Spanner, a fully managed relational database service running on Google Compute Engine (GCE) released in February 2017, has the scalability of NoSQL databases while retaining SQL compatibility, relational schemas, ACID transactions, and strong external consistency. Spanner is a sharded, globally distributed and replicated relational database that uses a Paxos algorithm for reaching a consensus among its nodes.

One alternative to Spanner, and the subject of this review, is CockroachDB, an open source, horizontally scalable distributed SQL database developed by ex-Googlers who were familiar with Spanner. CockroachDB borrows from Google’s Spanner for the design of its data storage system, and it uses a Raft algorithm for reaching a consensus among its nodes.

Like Cloud Spanner, CockroachDB is a distributed SQL database built on top of a transactional and consistent key-value store, in CockroachDB’s case on RocksDB. CockroachDB’s primary design goals are support for ACID transactions, horizontal scalability, and (most of all) survivability, hence the name.

CockroachDB is designed to survive disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention. Of course, to accomplish that you need to run a cluster of many instances of CockroachDB’s symmetric nodes, using multiple disks, machines, racks, and datacenters.

Unlike Cloud Spanner, which uses the TrueTime API available for time synchronization in Google data centers, CockroachDB can’t count on the presence of atomic clocks and GPS satellite clocks to synchronize the time accurately across nodes and data centers. That has a number of implications. To begin with, Google TrueTime gives an upper bound for clock offsets between nodes in a cluster of seven milliseconds. That’s small enough that a Spanner node just waits seven milliseconds after a write before reporting that a transaction has committed, to guarantee external consistency.

To continue reading this article register now