View all

Gartner predicts that by 2022, 75% of all databases will be deployed in the cloud. The findings shouldn’t come as a surprise: on-premise data centers are slowly being phased out as companies realize the many benefits to running a database in the cloud.

As organizations migrate to the cloud, they need a cloud-native, relational database to help them move all their applications to this new environment. Over the last ten years, the infrastructure that runs our applications has fundamentally changed. As we move to the cloud, we now have to think about managing workloads in an environment where we don’t have tight control over the infrastructure that hosts our applications. Things like “how can I recover my data?” and “what happens if my instance fails?” are very different when you host applications in the cloud. And we’re doing it at a scale that was once only considered by a handful of companies worldwide. Largely, these changes have been positive. Launching a new technology no longer requires months of planning, procuring, and commissioning hardware. Our individual apps have become a combination of micro-services that work together and can be set up to scale dynamically as traffic demands. We can try out something new without having to convince management that it’s worth a capital investment. However, when it comes to data, it hasn’t been easy to make the transition.

Keith McClellan

July 17, 2020

CockroachDB’s 20.1 release supports lateral joins, which can dramatically reduce the lines of code needed to arrive at key business analytics. Today, I’m going to walk you through a demo of lateral joins and showcase how you might use them to run analytic queries directly in CockroachDB.

Andy Woods

July 16, 2020

In 2018, CockroachDB implemented a cost-based query optimizer from scratch, which has been steadily improved in each release. The query optimizer is the part of the system that understands the semantics of SQL queries and decides how to execute them; execution plans can vary wildly in terms of execution time, so choosing a good plan is important. In this post we go over some of the optimizer-related improvements in CockroachDB v20.1.

Before meeting a candidate, your brain has already started playing some unconscious games. You get excited if you see a candidate who went to the same school as you. You get irritated if you see a company you don't like. You have already started making assumptions simply based by what is on paper, showing the power unconscious bias can have in the hiring process.

Lindsay Grenawalt

July 9, 2020

For the past four months, I’ve worked as a backend engineering intern with the incredibly talented engineers of the Cockroach Labs SQL Execution team to unlock the full potential of the vectorized engine ahead of the CockroachDB 20.1 release. During this time, I focused on improving the algorithm behind some of CockroachDB’s SQL operators, to reduce memory usage and speed up query execution. In this blog post, I will go over the improvements that I made to the algorithm behind the unordered distinct operator, as well as new algorithms that address some existing inefficiencies.

Every startup has a choice: Begin building with something familiar (Postgres, MySQL…) or begin building with something new (CockroachDB). Using a familiar database means engineers can hit the ground running and begin building on a trustworthy platform. Using a new database will require research, testing, and a period of time for acclimation. On the surface this looks like a simple decision: start building faster with a familiar database. Peel the onion back one more layer and it becomes clear why so many growth-stage companies are deciding to start with CockroachDB rather than Postgres or MySQL.

Dan Kelly

July 7, 2020

Late last year, we shipped v1 of our vectorized execution engine. It enables column-based query execution and speeds up complex joins and aggregations, improving analytical capabilities in CockroachDB (which is first and foremost optimized for OLTP workloads). v1 of the engine didn’t support disk spilling, which meant it couldn’t execute certain memory-intensive queries if there was not enough memory available. Starting in CockroachDB v20.1, these queries fall back to disk (also known as “spilling” to disk).

Healthcare industry companies count on their database solutions to protect sensitive data and to deliver consistent performance. They also need the database to streamline communication between a complicated backend full of disparate systems. For most of the last 30 years this meant relying on Oracle because Oracle delivers the consistency required in an industry where lives are at stake and data must always be correct. The rise of cloud-native, distributed SQL database technology that offers a high level of consistency and horizontal scale is giving the healthcare industry a more flexible option.

Dan Kelly

June 29, 2020