View all

The pgwire module handles the communication with the client application, and receives the query from the client. The SQL text is analyzed and transformed into an Abstract Syntax Tree (AST). This is then further analyzed and transformed into a logical query plan which is a tree of relational operators like filter, render (project), join. Incidentally, the logical plan tree is the data reported by the EXPLAIN statement. The logical plan is then handed up to a back-end layer in charge of executing the query and producing result rows to be sent back to the client.

A version of this blog post was originally published on May 1, 2017 and has been modified to provide the newest information available. With the recent 1.0 release, CockroachDB is now a production-ready database. 1.0 showcases the core capabilities of CockroachDB, while also offering users improved performance and stability with a cloud-native architecture that flexibly supports all manner of cloud deployments. It encompasses the core features that allow our users to run CockroachDB successfully in production. Now that the dust has settled on our 1.0 release, I wanted to share how we defined our target use case and dive into the actual product features that support running that use case in production.

Join the Cockroach Labs founders for an unscripted conversation about the dirty details building 1.0 and in achieving consensus across three co-founders. What do they wish they could have made it into the 1.0 release? What are they most excited about in this production-ready release? And what happens when they disagree with each other?

Jessica Edwards

May 11, 2017

Today, we are pleased to announce the release of CockroachDB 1.0, the first open source, cloud-native SQL database. We’re also announcing a series B fundraise from investors who share our vision. The launch of 1.0 marks our graduation from beta to a production-ready database, designed to power business at any scale from the startup to the enterprise. A brief introduction is in order. While databases aren’t generally considered the most thrilling subject in technology news, ignoring them would be a mistake. Understanding the ongoing evolution of databases brings into focus a ruthless arms race between what businesses need to do with data, and what existing technologies struggle to provide. The most insistent pressures have forced databases alternatively to become faster, bigger, and more reliable. Then again: faster, bigger, and more reliable. And the cycle continues.

Spencer Kimball

May 10, 2017

CockroachDB recently gained support for Unicode collation, a standard for ordering strings in the different ways that our users around the world expect. This post describes the motivation for Unicode collation as well as the implementation challenges in providing collated strings as a first-class type. Collated strings are documented here. Note that CockroachDB doesn’t support every use of collation that PostgreSQL does, due in part to implementation deficiencies that we plan to address and in part because we believe that the bugs and performance problems caused by implicit type conversions outweigh their convenience. We’ve left the door open for full support, however.

Calling all database and infrastructure experts: get ready to nerd out with the best CockroachDB devs in your city! A year after our Beta release and a shortly before CockroachDB 1.0 becomes available for download, we are excited to announce the newly minted CockroachDB User Groups. We are kicking off our user groups April 4th and 5th, with inaugural events in New York City and San Francisco respectively.

With the release of CockroachDB beta-20170223, we’d like to announce a new arbitrary-precision decimal package for Go: apd. This package replaces the underlying implementation of the DECIMAL type in CockroachDB and is available for anyone to fork and use. Here we will describe why we made apd, some of its features, and how it improved CockroachDB.

I recently came across an old piece on The Atlantic on design research. Author and educator Jon Freach wrote, “Design can exist without ‘the research.’ But if we don't study the world, we don't always know how or what to create.” His words resonated with me. Designers are innate problem solvers. Without “the research,” we wouldn’t know what problems to solve and for whom we create solutions. One may argue that people generally don’t know what they want, and it’s up to us creating something new to spark desire. Yet, that creation process isn’t sheer magic being pulled out of thin air. The creation process usually involves painstaking investigation of the world and deep inquiry on how we can make it better. In other words, the shiny new wonderful thing that everyone wants is just a reincarnation of a similar idea but thoroughly interrogated and researched. Smartphones existed before the first iPhone was introduced. Group chat was invented long before Slack was a company. Similarly, databases are not a new topic. When I started several months ago, I wanted to do “the research” to figure out how this new database with a funny name could spark desire. My first quest was to investigate pain points people have with their current database solutions, and how they first hear about, test and adopt alternative options. Having not been properly trained as a researcher, I hacked together a study with the help of GV’s extensive resources and recruited and interviewed a few developers and CTOs. Yet, the data I collected was scattered, with no clear pattern across the demographics. Given how crucial the questions were to understanding of our audience, I decided to reevaluate the research process, and redo the study with some tweaks. Here’s what I’ve learned from doing the same study twice, and why the second study was a lot more effective.

Almost a year ago, we wrote about our use of Jepsen in testing CockroachDB. As we prepare for CockroachDB 1.0, we wanted to get independent verification of our findings, so last fall we hired Kyle Kingsbury, the author of Jepsen, to review our tests and add more of his own. Last week, Kyle published his results. Kyle’s testing found two new bugs: one in CockroachDB’s timestamp cache which could allow inconsistencies whenever two transactions are assigned the same timestamp, and one in which certain transactions could be applied twice due to internal retries. Both of these issues were fixed (the first in September and the second in October), and the expanded Jepsen test suite is now a part of our nightly test runs. Now we can say with more confidence that CockroachDB meets its guarantee of serializability (the highest ANSI SQL isolation level) for all SQL transactions.