One of the main reasons our customers choose CockroachDB is the easy horizontal scalability it offers, while maintaining data consistency with serializable isolation. This combination lets customers run critical OLTP workloads, like financial ledgers and e-commerce shopping carts, at large scale without the hassle of legacy sharding. With every release, we make significant investments in improving CockroachDB’s performance and scale. We measure CockroachDB’s performance through many diverse tests, including the industry-standard TPC-C benchmark to track our progress across releases. Our latest version, CockroachDB 20.2, passed 140K warehouses with a maximum throughput of 1.7M transactions per minute (tpmC) on TPC-C. This represents a 40% improvement with the same resources as compared to the results previously reported with CockroachDB 19.2 in this post. Additionally, CockroachDB 20.2 was able to load TPC-C 140K in less than 3 hours compared to the ~20 hours it took to load TPC-C 100K in 19.2. This improvement was the result of faster bulk-data loading, which built upon work in Pebble, CockroachDB’s new storage engine.

I ended an amazing internship this past fall on the KV (Key-Value) team at Cockroach Labs (responsible for the transaction, distribution and replication layers of CockroachDB). This blog post delves into my work on adding native support for creating hash sharded indexes in CockroachDB, as a way to significantly improve performance on sequential workloads. CockroachDB uses range partitioning by default, as opposed to hash partitioning. As explained in our CTO Peter Mattis’s blog post, a key-value store with range partitioning resembles a distributed balanced tree whereas one with hash partitioning is closer to a distributed hash map. In particular, range partitioning outperforms hash partitioning for the most common SQL workloads like range scans. However, load under range partitioning can become imbalanced for access patterns that focus on a specific range of data, since all traffic is served by a small subset of all the ranges. Sequential insert traffic is a common example of such an access pattern and is much better suited to hash partitioning.