View all

The development of the relational model heralded a big step forward for the world of databases. A few years later, SQL introduced a rich vocabulary for data manipulation: filters, projections, and—most importantly—the mighty join. Joins meant that analysts could construct new reports without having to interact with those eggheads in engineering, but more importantly, the existence of complex join queries meant that theoreticians had an interesting new NP-hard problem to fawn over for the next five decades.

If you’re reading this, you’re surely familiar with the arguments for high availability: services are only useful when they’re online. Unavailable services not only lose money, but also deteriorate your credibility in customers’ eyes. This could lead to immeasurable costs to your company in the future. Given that CockroachDB got its name because of its ability to survive failures, we thought we would cover some architectural considerations when building high availability services on top of Cockroach.

Many inky, black pixels have been rendered over GDPR. It dramatically shifts the landscape for businesses with any EU users, so there are a lot of questions about what it means in general, as well as what it takes to actually comply with it. In this post, we’ll cover how Cockroach Labs conceives of GDPR’s major tenants (known as Data Subject Rights, which translates to “things you must do for your users”), as well as some considerations as to what it actually means for your company’s database.

CockroachDB provides scale without sacrificing SQL functionality. It offers fully-distributed ACID transactions, zero-downtime schema changes, and support for secondary indexes and foreign keys. But what about some of the additional benefits NoSQL databases provide such as the ability to use semi-structured data? CockroachDB listened to our customers and realized that we needed to provide options for managing rapid development, data without a clear schema or whose schema you do not control, and impedance mismatches. That’s why we are excited to support JSON in 2.0! Previously we’ve shown you how we implemented JSON and inverted indexes as well as a few examples. This blog post will explain when you might want to leverage these features.

Andy Woods

June 21, 2018

Last year on the blog, we shared our point of view on product design and research, two of the three main responsibilities of the Design team at Cockroach Labs. The one that we haven’t discussed yet is brand. Despite having a distinct and memorable name like Cockroach Labs, nailing our brand hasn’t been simple and is still a work-in-progress. From day one, our mission has been to make data easy. But what does a brand that makes data easy look like? That’s the question that keeps the design team up at night. Eight months ago, we attempted to answer this question in a true startup fashion: pick one aspect of the visual system that’s representative of the brand, launch experiments, and iterate until we find what sticks.

May 25, 2018 has loomed over businesses for two years as the day the General Data Protection Regulation (GDPR) takes effect––and that day has finally arrived. If the number of "Updates to Our Privacy Policy" emails I've received in the last week are any indication, people are still hard at work trying to make GDPR compliance happen. However, unlike the cleanly cut deadline of filing your taxes, meeting GDPR's regulations isn't something most companies will complete today. According to Crowd Search Partners' GDPR report, as many as 60% of companies, as of today, fail to comply.

CockroachDB makes it possible to support a global customer base while remaining compliant with data privacy regulations. Operators interact with a single logical control plane that they can use to define how they want CockroachDB to store their row-level data. Meanwhile, developers continue to interact with our PostgreSQL-compatible API that transparently handles distributing queries across a global cluster. With our 2.0 release, we introduced a new cluster visualization in our web UI to help operators monitor a global cluster.

Over the past year, Kubernetes––also known as K8s––has become a dominant topic of conversation in the infrastructure world. Given its pedigree of literally working at Google-scale, it makes sense that people want to bring that kind of power to their DevOps stories; container orchestration turns many tedious and complex tasks into something as simple as a declarative config file.

The three design principles of CockroachDB are correctness, stability, and performance. Having achieved our correctness and stability goals with CockroachDB 1.0 and 1.1, we focused heavily on performance with CockroachDB 2.0. For more information on which benchmarks matter, or to see a comparison between CockroachDB 1.1 and 2.0, you can read CockroachDB 2.0 Makes Significant Strides. Today we are releasing a comprehensive whitepaper that demonstrates how CockroachDB achieves high OLTP performance of over 128,000 tpmC on a TPC-C dataset over 2 terabytes in size. This OLTP performance is over 10x more TPC-C throughput than Amazon Aurora, in a 3x replicated deployment with single-digit seconds recovery time and zero-downtime migrations and upgrades. This far surpasses a typical active-passive database deployment with manual failure recovery. CockroachDB achieves this in serializable isolation, unlike competing databases that sacrifice isolation for performance. We’re very excited to talk about performance, and have taken care to make this more than just an announcement with vague numbers. In keeping with our open source philosophy, our whitepaper contains a step-by-step reproduction of instructions to verify all our performance claims, as well as context on our benchmarking philosophy and practices. We don’t just want you to take our word for our performance numbers, we’d like to arm you with all the tools you need to check it out for yourself! In this post, we’d like to cover some brief highlights, but do check out the whitepaper for more details and a fully reproducible test script.