CockroachDB, the database that just won’t die

There is an art to engineering, and sometimes engineering can transform art. For Spencer Kimball and Peter Mattis, those two worlds collided when they created the widely successful open-source graphics program, GIMP, as college students at Berkeley.

That project was so successful that when the two joined Google in 2002, Sergey Brin and Larry Page personally stopped by to tell the new hires how much they liked it and explained how they used the program to create the first Google logo.

In terms of good fortune in the corporate hierarchy, when you get this type of recognition in a company such as Google, there’s only one way you can go — up. They went from rising stars to stars at Google, becoming the go-to guys on the Infrastructure Team. They could easily have looked forward to a lifetime of lucrative employment.

But Kimball, Mattis and another Google employee, Ben Darnell, wanted more — a company of their own. To realize their ambitions, they created Cockroach Labs, the business entity behind their ambitious open-source database CockroachDB. Can some of the smartest former engineers in Google’s arsenal upend the world of databases in a market spotted with the gravesites of storage dreams past? That’s what we are here to find out.

Berkeley software distribution

Mattis and Kimball were roommates at Berkeley majoring in computer science in the early-to-mid-1990s. In addition to their usual studies, they also became involved with the eXperimental Computing Facility (XCF), an organization of undergraduates who have a keen, almost obsessive interest in CS.

The way the group works is that members decide on a project to deliver and then meet periodically throughout the semester to present their work and get advice on how to move forward with their efforts. It’s hardcore. As past member Walter Rader explained in a 2003 article, “It’s like Darwinism: If you’ve got a bad idea, you get flack for it and the idea dies.”

It was in this fierce crucible of XCF that Mattis and Kimball in 1995 created GIMP, an open-source alternative to Adobe Photoshop, perhaps the most popular photo editor ever made. Looking back to the days when he was collaborating on GIMP with Mattis, Kimball reflects, “From the first line of source code to the last, GIMP was always my ‘dues’ paid to the free software movement. After using emacs, gcc, Linux, etc., I really felt that I owed a debt to the community that had, to a large degree, shaped my computing development.”

Their work on GIMP would prove to be prescient of what they would do with CockroachDB. “We built GIMP for exactly the same reasons we built Cockroach, which was we really wanted to use a sophisticated image manipulation program using Unix, but it didn’t exist,” Kimball said. “So we scratched our own itch. In 2015, when I started getting very serious about building Cockroach, we had a similar mindset: We need this, it doesn’t exist, and this is something that can make a big difference to a lot of people in the world.”

GIMP wound up being a smashing success. Kimball, musing on meeting Larry and Sergey and their experience with the photo editor, said, “GIMP is the gift that keeps on giving.”

Building at web scale in the early days of Google

While Mattis graduated from Berkeley in 1995, Kimball had two more years to go. The two stayed in touch and joined a number of different ventures in the raging heyday of the dot-com bubble. Then in 2002, Mattis got a job at Google. He liked the company so much that he did the legwork to bring Kimball into Google three months later. The third co-founder of Cockroach Labs, Ben Darnell, arrived at the search company around that time as well.

Google was growing at an astounding rate and struggling to manage its data. Its AdWords service alone was generating historic amounts of data that needed to be stored and processed. AdWords was a gold mine, but it was also bringing Google’s databases to their knees.

Kimball got a close look at the problem. “When I got there, I was on the AdWords product. They were having huge problems with the databases. They were doing sort of a sharded architecture with MySQL. It was creaking under the inappropriateness of the architecture,” he said. “They went from one shard, to two, four to eight, 16 to 32. Google eventually outlawed that sharding architecture, which is fascinating because the rest of the Silicon Valley startups in that era all leaned into that architecture. Google said that they’re going to build something better.”

They did, but not before going down a blind alley.

As a first attempt, Google tried a NoSQL solution. Unlike SQL databases, which segment and store data uniquely over many tables, a NoSQL database stores data as a collection of documents. One major drawback with the design of NoSQL databases of that era — including Google’s — is that the technology did not support transactions.

Transactions are essential when modifying data. The usual example of a transaction is making a travel reservation that involves buying an airplane ticket, reserving a hotel room and renting a car. Typically in enterprise data architectures, the data for flights, hotels and cars live separately. Thus, in order for a travel reservation to be successful, all three pieces of data need to be stored properly and updated synchronously.

Transactions solve this sort of problem, as can be seen in Figure 1. First the airplane ticket is bought, then the hotel reservation is made, and finally the car is rented. If all goes well, the transaction is committed. If something goes wrong at any point, such as the car rental database being down, the database will cancel the airplane ticket and hotel reservation, and then report the transaction as failing.

The benefit of a transaction is that it ensures data integrity at the storage layer, freeing developers to focus on their application’s capabilities. The downside is that it can drastically limit a database’s performance, since each transaction can lock tables in a database, preventing other users from using it. As millions and then billions of users flooded onto the internet, supporting many simultaneous users across applications became an absolute imperative.

Despite that downside, Google was focused on developing its NoSQL technology. “The reports from the application developers at Google were unequivocal. They were uniformly saying that NoSQL it’s cool that you can elastically scale and everything, but you don’t have transactions anymore,” Kimball said. “The AdWords team said, ‘We have 500 tables, complex relations and there is a sophistication in SQL databases that you just can’t eschew and expect to do the same kinds of things you did before.’”

Persistent consternation from application developers led Google in 2006 to create a relational database designed to meet the needs of projects that required transactions on a global scale. Google called it Spanner, a technology that remains a core service of Google Cloud today. “They brought SQL back in because they said we want to move AdWords in that direction,” Kimball said. “By the time I left [Google], Spanner was underlying most of what Google does.”

The fight over the infrastructure at Google would ultimately spread across the burgeoning internet economy. “It was like looking into a crystal ball and asking, “What are the parameters of a database that people are going to want in 2020?” Well, I knew in 2010, because Google was answering this question and I was there,” Kimball said.

All three CockroachDB founders eventually left Google. Darnell left in 2009 to join the startup FriendFeed, which was acquired by Facebook in 2009 and eventually shut down. Kimball and Mattis left Google in 2012 to start a company called Viewfinder. Darnell, who by 2012 was working at Dropbox, joined them at Viewfinder a few months later.

Viewfinder, Square and solving the problem of distributed transactions

It was at Viewfinder where the trio discovered that the need for a “CockroachDB” became glaringly apparent not just at Google, but at all companies operating on the web. Viewfinder was a photo-sharing service on the order of Flickr and with the potential of Snapchat or Instagram, intended to provide a first-class user experience to millions of subscribers worldwide. This meant having data in a variety of formats immediately accessible for users anywhere on the planet, whether they were in Australia, Europe or the United States.

At first, the startup used DynamoDB, Amazon Web Service’s NoSQL database, but the effort was a continuous struggle. “We spent about a third of our engineering time battling database problems, which is not unusual,” Kimball said.

The company was finding it hard to get consumer traction, and ultimately, Viewfinder was acquired by the digital payments company Square in 2013. Given its focus on worldwide financial transactions, Square needed the engineering talent as it addressed the challenges of data management on a global scale.

The company gave Kimbal, Mattis and Darnell a fresh start and a wide berth. During their time at Square, they created an open-source design document that described exactly how a relational database that supports transactions on a global scale should work. Their document attracted many of the same people in the open-source community that had read the paper that Google published about Spanner.

Their paper also attracted the attention of a few venture capitalists willing to invest in the database market. In 2015, Cockroach Labs was born, but it would take another year of work until the product was ready for a beta release.

Building a database for global scale

Finding significant inspiration in Google’s Spanner paper and their own design document, the three co-founders diverged in their licensing of the underlying technology. Unlike Spanner, CockroachDB is open-source code, and it’s available to this day on GitHub.

CockroachDB is designed to allow developers to create databases that span multiple geographic regions. The technology has three key features, which we’ll explore further in part two of this EC-1. First, it allows data to be localized in specific geographical regions. So, data related to New York users could be stored in an East Coast data center. Second, it guarantees that all data is accurate whenever the database is queried. And third, it ensures that data is always available even if a data center goes down through robust data replication capabilities.

Put these three features together and you have a database that has the potential to be an industry-defining juggernaut. There’s a reason it’s called CockroachDB, after all. “It’s a testament to its resilience. It’s indestructible, just like a cockroach,” Kimball says. (It’s also memorable, at least as far as database naming goes).

The original revenue model was to sell support services at the enterprise level and charge enterprise licensing fees to companies that needed advanced features. But that was then and this is now. Companies can still buy enterprise licenses and support services for CockroachDB, but Cockroach Labs is giving significant attention to its database-as-a-service (DBaaS) product CockroachCloud, which we will explore further in part three.

Cockroach Labs has come a long way since its founders left Google in 2012. It’s based in New York City, and contrary to the conventional thinking that says that New York is best suited to fintech and advertising companies, the city has exactly the type of technical talent that the company needs. When talking about hiring developers in New York City versus those in Silicon Valley, Kimball says, “The folks here are less mercenary than in the Bay Area. The New York ecosystem has grown as quickly as we have.”

The company has enjoyed year-over-year growth of just under 300%, and its 2020 revenue is double that of 2019, though it declined to provide more specific figures. Today, Cockroach Labs has over 250 employees and has received investments from the likes of Benchmark, GV, Index Ventures and Redpoint totaling more than $350 million, according to Crunchbase.

Perhaps most importantly, its open-source codebase has over 300 external contributors. Cockroach Labs was started by developers and stays true to its roots to this day — the company invests a good deal of money in developer support and training, too.

Kimball, Mattis and Darnell think that the insights they gained from their time at Google and the two other startups afterward set CockroachDB apart from other databases. They’re not reinventing the wheel, but evolving a technology that began as an idea at Google that they’ve extended over the years. Given its history, engineering acumen, the breadth of developer interest and its financial resources, CockroachDB, and by extension CockroachCloud, are going to have a significant presence in the world of distributed databases and database services, now and in the foreseeable future.

However, to understand that future requires understanding CockroachDB’s underlying product, which is where we turn to in part two of this EC-1.

---

CockroachDB EC-1 Table of Contents

• Introduction
• Part 1: Origin story
• Part 2: Technical design
• Part 3: Developer relations and business
• Part 4: Competitive landscape and future

Also check out other EC-1s on Extra Crunch.

---