View all

Cockroach Labs was founded on a hypothesis: modern, cloud-native applications will need a new type of database built on a distributed architecture to provide bulletproof resilience and elastic, effortless scale, and we can deliver it. We’ve been humbled and encouraged to see validation of our hypothesis over the past four years, from buzz and feedback on Hacker News, to open source adoption, to Github stars. Since launching our commercial product in 2018, we’ve seen companies large and small (including Equifax, Bose, and Comcast) adopt CockroachDB as their database of choice for mission-critical applications. And in the last twelve months, we’ve seen our first-year customers on average more than double the size of their CockroachDB deployments.

My guiltiest pleasure right now is watching apocalypse films. It’s less escapism than it is catharsis, and there’s usually a happy ending (or at the very least---they have an ending). When you watch these apocalyptic movies, the audience is always focused on the hero, holding the door closed against some encroaching danger. Few people are paying attention to the guy in the corner of the room sitting with others, telling some wild story or caught in the middle of some elaborate joke, trying to get a smile out of people in crisis.

* As of CockroachDB 23.1 we no longer use the duplicate indexes topology pattern. Instead, we use global tables. When you’re distributing a SQL database geographically, it can be tough to get fast application performance. Data often has to make long, round trip journeys across the world and is restricted by a speed limit (the speed of light).

Piyush Singh

April 14, 2020

To the Cockroach Labs community, These are unprecedented times. We are all dealing with tremendous change and uncertainty as the impacts of COVID-19 reverberate around the world. We hope you, your team, and your families are and remain safe.

Spencer Kimball

April 6, 2020

If your company has a global customer base, you’ll likely be building an application for users in different areas across the world. Deploying the application in just a single region can make high latencies a serious problem for users located far from the application’s deployment region. Latency can dramatically affect user experience, and it can also lead to more serious problems with data integrity, like transaction contention. As a result, limiting latency is among the top priorities for global application developers. In this blog, we walk you through a low-latency multi-region application that we built and deployed for MovR, a fictional vehicle-sharing company with a growing user base. The MovR application is a Flask web application, connected to a CockroachDB cluster with SQLAlchemy. We deployed the application in multiple regions across the US and Europe, using Google Kubernetes Engine, with some additional Google Cloud Services for load balancing, ingress, and domain hosting. For the database, we used a multi-region CockroachDB Dedicated deployment on GCP. The application source code is available on GitHub, and an end-to-end tutorial for developing and deploying the application is available on our documentation website.

Back in 2015 the early Cockroach Labs engineers made a decision to write this massive, complex application in Go. Since then we have, on many occassions, discussed our use of Go in blogs and on stage.

Dan Kelly

March 18, 2020

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.

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).

This past year, the Cockroach Labs marketing team introduced a novel way of collecting leads at large events. Instead of giving away swag (socks, tshirts, pens, etc.) to every person we met, we donated money to a non-profit. Our “contacts for charity” program was wildly successful, and at AWS Reinvent and KubeCon North America last year, we more than tripled our lead capture goals and donated over $14,500 to Women Who Code, the largest and most active community for technical women in the world.

Jim Walker

March 12, 2020