In this post we’re going to talk about one of the techniques that can be used in CockroachDB for getting good performance from databases accessed from multiple geographical regions: follower reads. These are operations presenting a slightly stale view of data, which can be served with local latencies from different regions.

In a cluster spanning multiple geographical regions, Global Tables let database clients in any region read data with region-local latencies. Imagine a table with data that is read from all over the world: say, for example, a table of exchange rates in a global bank’s database. Queries ran on behalf of users anywhere might access these rates. This is in contrast to other types of data (say, a user’s account data) which have an affinity to the user’s own region. Global Tables make accessing these exchange rates fast.

Follower reads are a key feature that developers wanting to use multi-region databases should understand. We originally introduced them in this blog post, and later documented their use here. In this post, we’ll quickly review the basics of follower reads, highlight some potential issues, and propose a new type of follower reads that we’re exploring to address those issues: bounded staleness reads.

This post was originally published in 2017, upon announcing that CockroachDB’s support for Hibernate was in beta. Today, we’re excited to announce some big news: the CockroachDB dialect for Hibernate is officially available! 🥳 Hibernate now offers first-class support for CockroachDB. You can read more about the dialect, and our journey to get there, in this blog post.

We didn’t implement SELECT FOR UPDATE to ensure consistency. Unlike Amazon Aurora, CockroachDB already guarantees serializable isolation, the highest isolation level provided by the ANSI SQL standard. Contention happens. And application developers shouldn’t need to risk the integrity of their data when transactions contend. To combat this, CockroachDB must occasionally return errors prompting applications to retry transactions that would risk anomalies, such as write skews. This means that just like with PostgreSQL in serializable isolation, developers need to implement retry-loops for contended transactions. For developers accustomed to relational databases with lower isolation levels, this can be an unfamiliar pattern.

In December 2019, we published the 2020 Cloud Report and an accompanying blog post, which summarized original research we conducted benchmarking the performance of Amazon Web Services (AWS), Microsoft Azure (Azure), and the Google Cloud Platform (GCP).

Since 2017, Cockroach Labs has run thousands of benchmark tests across dozens of machine types with the goal of better understanding performance across cloud providers. If there’s one thing we’ve learned in our experiments, it’s this: benchmarking the clouds is a continuous process. Since results fluctuate as the clouds adopt new hardware, it’s important to regularly re-evaluate your configuration (and cloud vendor).

Distributed ACID transactions form the beating heart of CockroachDB. They allow users to manipulate any and all of their data transactionally, no matter where it physically resides. Distributed transactions are so important to CockroachDB’s goal to “Make Data Easy” that we spend a lot of time thinking about how to make them as fast as possible. Specifically, CockroachDB specializes in globally distributed deployments, so we put a lot of effort into optimizing CockroachDB’s transaction protocol for clusters with high inter-node latencies.

CockroachDB is a cloud-neutral database, which means it eliminates dependencies on a particular cloud environment and gives you the flexibility and choice to run it anywhere you like. We are committed to this principle and in order to deliver on this promise, we systematically deploy and test CockroachDB clusters on the three leading US cloud providers: Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.