View all

In 2016, LinkedIn chose not to comply with Russia's requirement for data to be stored locally. As a result, they were kindly blocked from doing business in the country. Facebook and Twitter, on the other hand, both decided that compliance in Russia is worth the effort. Neither has fully met Russia's requirements but they have shown enough progress to avoid being blocked.

Dan Kelly

March 19, 2019

GDPR went into effect less than a year ago. And still, the era of conducting global business with limited legislative obstructions already feels like some free-spirited, far away past. Right now the global landscape of data protection law is littered with obstacles and exceptions. GDPR has been the loudest but there are plenty of other regions and countries with regulations in place. Even within the E.U., countries like Germany and Switzerland have their own unique protection regulations. Russia and China have very draconian laws, and they're changing quickly. There are around 120 countries now with data protection laws in place.

Spencer Kimball

February 26, 2019

One small step for Cockroach Labs, one giant leap for our release numbering. Since our initial launch, Cockroach Labs has used semantic versioning in our release cycle guidelines. Two years, one major release, and n-patch fixes later, we're making the switch to Calendar Versioning. This means subscribers to our release notes will see quite the jump in today's version numbering, from last week's 2.1.5 to today's 19.1 beta.

Peter Mattis

February 25, 2019

Since the pre-1.0 betas of CockroachDB, we've been using Jepsen to test the correctness of the database in the presence of failures. We have re-run these tests every night as a part of our nightly test suite. Last fall, these tests found their first post-release bug. This blog post is a more digestible walkthrough of that discovery (many of the links here point to specific comments in that issue's thread to highlight the most important moments).

Ben Darnell

February 21, 2019

Which is worse...? One of your users goes to check her bank balance in your app, and the service is down, or, One of your users goes to check her bank balance in your app and there's a data inconsistency. Engineers are frequently faced with this false tradeoff: do you place a higher premium on data correctness, or high availability? This problem only becomes more complicated when you begin dealing with users distributed across broad geographies. When IT experts consider high availability infrastructure for mission-critical services, their minds often leap to Oracle as the preeminent service provider. But Oracle's database was designed in a pre-cloud world, and the means by which it achieves high availability on geo-distributed workloads are complex. Oracle requires a staggering number of technologies that must be implemented, and still, their solutions can allow potentially costly anomalies into your data. As a cloud native database, CockroachDB introduces a new way of providing always-on availability, strong data consistency, and distributed performance. Today, we're releasing a side-by-side comparison of CockroachDB and Oracle to help you get a better understanding of the architecture (and cost) of setting up a highly available distributed service.

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.

Andy Woods

February 7, 2019

For the past four months, I've been working with the incredible SQL Execution team at Cockroach Labs as a backend engineering intern to develop the first prototype of a batched, column-at-a-time execution engine. During this time, I implemented a column-at-a-time hash join operator that outperformed CockroachDB's existing row-at-a-time hash join by 40x. In this blog post, I'll be going over the philosophy, challenges, and motivation behind implementing a column-at-a-time SQL operator in general, as well as some specifics about hash join itself.

In September of 2020 we introduced our own homecooked replacement for RocksDB - a storage engine called Pebble. You can read about our reasons for the switch in this blog. We have tremendous respect and appreciation for RocksDB and continue to recommend it. … If, on a final exam at a database class, you asked students whether to build a database on a log-structured merge tree (LSM) or a BTree-based storage engine, 90% of your students would probably respond that the decision hinges on your workload. “LSMs are for write-heavy workloads and BTrees are for read-heavy workloads”, the conscientious ones would write. If you surveyed most NewSQL (or distributed SQL) databases today, most of them are built on top of an LSM, namely, RocksDB. You might thus conclude that this is because modern applications have shifted to more write-heavy workloads. You would be incorrect.

CockroachDB supports ACID transactions across arbitrary data in a distributed database. A discussion on how this works was first published on our blog three years ago. Since then, a lot has changed. Perhaps most notably, CockroachDB has transitioned from a key-value store to a full SQL database that can be plugged in as a scalable, highly-available replacement for PostgreSQL. It did so by introducing a SQL execution engine which maps SQL tables onto its distributed key-value architecture. However, over this period of time, the fundamentals of the distributed, atomic transaction protocol at the core of CockroachDB have remained untouched 1.