View all

Our latest CockroachDB Feature of the Week, core changefeeds, is an exciting new way for event-driven apps to consume data from CockroachDB. With the CHANGEFEED FOR statement, a SQL client can tell the database to monitor a table and tell it when writes take place. CockroachDB will then hold the connection open until the client closes it and stream records to the client for all writes. You can use changefeeds to build event-driven applications, perform data integration, and do all kinds of other tasks that depend on watching the state of a table.

Roland Crosby

July 30, 2019

Over the past few years, cloud conferences have taken center stage in the tech world. And as the three largest public cloud providers have grown, we’ve seen each launch a proprietary conference. Re:Invent, Next and Ignite have emerged as the main forums for practitioners tp share best practices and vendors announce major product advancements.

Jim Walker

July 23, 2019

Last week, our friends at Flowable released Flowable 6.4.2, which officially adds support for CockroachDB. Flowable provides a workflow and Business Process Management (BPM) platform for developers, system admins and business users, and now integrates with CockroachDB in just a few steps, thanks to a recent collaboration. Cockroach Labs and Flowable engineers have been teaming up since the early stages of CockroachDB because it makes deploying Flowable that much easier. Plus, as they write in their blog, “What makes CockroachDB very interesting for Flowable is that it’s scalable and distributed database... In the world of processes and cases, atomicity is utmost importance, as data correctness is sacred.”

Interviewing at Cockroach Labs comes with a twist. The interviewing process is unconventional by design—especially for non-engineering positions. The interviews are exercise-based, focused on practical, day-in-the-life style work tasks. Additionally, resumes are removed from the process to fight unconscious bias. The process is crafted thoughtfully and customized for each role being hired for, but it can be a bit daunting for candidates who are used to traditional interviews. As someone who recently experienced the process first-hand, I thought it would be beneficial for potential candidates to hear about my interviewing experience and gain insight into the process. For a little context, I joined Cockroach Labs in July as the new Technical Writer. In this post, I’ll be looking at the interviews from the perspective of a tech writer, but the process applies to all open roles across the company. The typical technical writer hiring process goes something like this: You apply for an online job posting with your resume and work samples. The HR representative conducts a phone interview. If selected, you are called for an in-person interview. The in-person interview generally entails a writing (read: grammar) exercise, followed by routine questions. The interview is usually conducted by two or three tech writers and the hiring manager. In my experience, the typical interview process relies on the candidate telling the hiring team what they can do, rather than showing what they can do. This does not necessarily translate into the candidate being a good fit for the position and the team. By contrast, the interview process at Cockroach Labs is cross-functional and exercise-based, which is unconventional, yet effective in the sense it not only helps the company decide if the candidate is a good match for the position, but also helps the candidate evaluate if the company is a good fit for them.

Amruta Ranade

July 11, 2019

Randomized testing is a way for programmers to automate the discovery of interesting test cases that would be difficult or overly time consuming to come up with by hand. CockroachDB uses randomized testing in many parts of its code. I previously wrote about generating random, valid SQL. Since then we’ve added an improved SQL generator to our suite called SQLsmith, inspired by a C compiler tester called Csmith. It improves on the previous tool by generating type and column-aware SQL that usually passes semantic checking and tests the execution logic of the database. It has found over 40 new bugs in just a few months that the previous tool was unable to produce. Here I’ll discuss the evolution of our randomized SQL testing, how the new SQLsmith tool works, and some thoughts on the future of targeted randomized testing.

Since the 2.1 release, CockroachDB has had a cost-based optimizer. Rewriting a big component of an existing system is always challenging. In particular, we really wanted to avoid regressing on any workloads, including simple transactional queries where the existing planner was already generating the best plan. A cost-based optimizer inherently does more work and thus involves longer planning times. To mitigate this, we worked on caching and reusing optimizer state across multiple instances of the same query. For now, we chose a conservative path: only cache state from which we can still generate the best plan (the one we would have generated without caching), making caching invisible to the user. We’ll start with an overview of the stages of the query planning process; then we’ll go over the methods clients can use to issue queries against CockroachDB, and finally we’ll discuss the caching work we have done to speed up query planning.

Everybody loves a fast query. So how can we make the best use of the existing information to make joins on sorted data faster? The answer is lies in vectorizing the merge join operator. Today we’ll be looking into what a merge joiner is (or what it used to be), followed by what vectorization means and how it changes the problem, and ending with how we decided to make the merge join operator faster and what this means for your queries.

Last year, we rebuilt our cost-based optimizer from scratch for CockroachDB’s 2.1 release. We’ve been continuing to improve the optimizer since then, and we’ve added a number of new features for the CockroachDB 19.1 release. One of the new features is automatic collection of table statistics. Automatic statistics enables the optimizer to make better decisions when choosing query plans.

It’s been a little over four years since we started our mission to deliver an enterprise-ready distributed SQL database. Today, we’re excited to release CockroachDB 19.1. With this release, we enhanced distributed SQL capabilities, and expanded upon enterprise-grade features for security and data integrations. 19.1 continues to solve the challenge of complex, distributed SQL while meeting all the “enterprise” requirements that are expected of a database. Here’s Nate Stewart, our VP of Product, with a quick intro on what you can expect in CockroachDB 19.1. And for a deeper tutorial with Nate, register for our CockroachDB 19.1 webinar.