Happy Anniversary, Cockroach Labs
It’s somewhat of an anniversary for Index and Cockroach (Ok, two months shy of the 5th anniversary…). In March 2016, we led the Series A in Cockroach Labs. While it may seem like a no-brainer today, it was not the most obvious investment at the time. Open-source was by no means mainstream. My partner, Danny, had invested in MySQL in the 2000s. The company arguably became the “grand-daddy” of a lot of the open-source investing that ushered in a new era for open source and for Index. MySQL taught us a lot about open-source databases.
A database, especially a transactional one, is the beating heart of any application. It’s where all the records are kept. It has to perform all the tasks requested of it from applications. It has to be incredibly robust because if the database goes, everything stops. It always has to be precise and correct. Being so mission-critical, it takes time for a database to earn the trust of developers. And, the more legitimate the application, the higher the bar for the database.
It’s also true that these fundamental characteristics of databases make them complex computer science problems. It’s really difficult to make a database fast, resilient, consistently accurate, scalable, and easy to use– all at once.
In addition to database fundamentals, investing in a SQL / relational database in 2016 broke from some trends that had permeated the market up to that point. There are always interesting new databases being invented. Computer Science majors take a database class in their senior year of college and decide that it would be cool to build a new one. The vogue architecture and technology 5 years ago were not SQL. The massive scale that the internet had brought about had birthed a genre of databases that were non-relational, document-based, spoke a dialect other than SQL, used “data lakes”, etc. Not that these were poor technologies, they were just very different from the MySQL, Postgres, or Oracle-style of relational, SQL databases. And in 2016, these latter databases felt like bell-bottoms in the 2010s. Nice relics and reminders of how our parents used to dress.
So, when we made the bet on Spencer, Peter, Ben, and the team, we had to believe a number of key theses. Some of these were about the technology itself and some of them were about the market. Among those, three were really critical:
SQL & Relational databases would make a major comeback
Originally developed in the 70s and mainstreamed in the 80s, SQL has been around forever, and it is the most common way that both applications and humans read and write to relational databases. Most readers will have some experience with a little SQL. It’s not the most intuitive language, but once you get the hang of it, it’s pretty powerful.
SQL does have its detractors. Most of the criticism centers around 3 factors: 1) it’s a pseudo-natural language (i.e. it tries to be too much like English, so it’s not a good programming language); 2) it’s a declarative language (i.e. programmers cannot tell SQL *how* to do a task, but rather ask for the result they want from the task); 3) it’s just old.
These issues notwithstanding, our bet on Cockroach was that SQL wasn’t going anywhere. The metaphor that I use for non-technical audiences is that SQL is a bit like English. The English language isn’t always obvious, it’s clumsy at times and hard to pronounce. It’s full of exceptions to the rule that drives ESL folks crazy. If you had to design a human language from scratch today, you wouldn’t create English. But, the one thing English has going for it is that large parts of the world speak English. There is *so much* English content out there, that English is here to stay.
The same is true for SQL. In fact, Cockroach and several other database companies like Snowflake and Starburst have broken down important technological barriers over the last 5 years that have enabled a new renaissance in SQL databases. In conquering the technical problems around scalability and cloud-readiness, the demand for SQL databases has exploded.
The Cockroach Labs team would overcome the technical challenge to create a world-class database
Relational databases that are transactional in their application have a twin requirement. First, they need to scale out *and* they need to have strong consistency. They need to scale out because these architectures allow for operations at Internet scale and responsiveness. In addition, the scale-out creates resilience because the database can have multiple copies of the same data in the event of an unexpected failure.
Second, transactional databases need to have strong consistency. This nuance is particularly important as it defines the difference between an analytical database and a transactional one. When performing a non-real-time application (like analytics) and data is stored in two copies of the database, the two copies only need to eventually agree on the data. But, when the application is transactional (say, withdrawing money from an ATM) all databases must agree on the correct data at all times.
When you think through it, scale-out and strong consistency work against each other. This is the problem that the Cockroach team solved and did so elegantly. In doing so, they opened up a new era for SQL databases.
Solving this technical challenge would unlock pent up demand
It took the Cockroach team time to develop a database that addressed these challenges and was performant enough for developers to begin to adopt in earnest. Today, CockroachDB has become a one-of-a-kind product. It runs natively in the cloud because of its scale-out nature. Developers can serve global customers faster and in their own legal jurisdictions. It’s made a “global” footprint affordable and easy to administer without compromising the transactional nature of any application. No other product in the market offers these capabilities. And, to add fuel to the fire, CockroachCloud allows developers to take advantage of the benefits of CockroachDB without the need to operate the product at all. Just point your application to it.
The flywheel of success
Of course, the company, Cockroach Labs has come a long way since 2016. The technology works and has been adopted by customers across the globe. Doordash, Comcast, eBay, SpaceX, Baidu, JP Morgan, and many others have put their mission-critical workloads onto CockroachDB and seemingly cannot get enough of it.
On DB-Engines, CockroachDB’s rank continues to rise, and it’s now the 33rd most popular relational database, impressive considering that it wasn’t a product 4 short years ago.
The company itself has matured from a couple dozen folks in a shared workspace when we invested to 180 employees. The exec team has grown with industry veterans like Jeff Miller running sales, Peter Guagenti heading marketing, Nate Stewart on product, Isaac Wong leading engineering, and Lindsay Grenawalt on people.
And, of course, Cockroach Labs has succeeded in raising an impressive amount of capital from a great group of investors in order to pursue their dream. The capital has allowed the company to double down on the technology, but also to drive the adoption of Cockroach Labs through GTM investments.
Journey ahead
Even with all this success, Cockroach’s journey is still beginning. The technological and community-based moat they have built is wide and deep. Whoever comes “next” will have a big hill to climb. A transactional database takes soak-time to mature. It is a composite of features in scale, performance, usability, and capabilities which are awfully hard to replicate in a short sprint.
The truth is that most of the world still runs on databases that were built in the 80s and 90s. And, it won’t be that way forever. Oracle became the business it is today on the back of its eponymous database. But, lock-in aside, very few of its customers love their Oracle database today. Cockroach Labs still has a lot of building to do, but the opportunity to transform the database world has never shone so brightly in front of them. Heady times for this amazing team of “roachers."
Published — Jan. 12, 2021