Cockroach Labs: A Cloud SQL Database Built for Survival with CEO Spencer Kimball

All right, Spencer, welcome back. So I was just looking. This is actually the fourth time that we feature Cockroach. The first time was actually in January of 2014, which feels crazy. Could it have really been January? I don't think the company got started till February.

Maybe it was before the company started. It was super early. And by the way, I'm a proud investor—I am—FirstMark is a proud investor in CockroachDB. And the story is that's how I crawled my way into the deal. They're saying, hey, there's actually a data community in New York, and that's for real. And people come and want to learn about technology. And I think you took pity on me. It's like, oh, this guy's trying hard, so we can let him in.

So I think that's—no, it's actually an honor to be part of the Data Driven at that time. I think we got some really interesting leads. I mean, it was early for our product, but just interest from folks in the community. So it was well worth doing it. And if anyone here is doing a startup and you get a chance to participate with Data Driven, I recommend it. Okay, well, great answer. Thank you. So that's 2014, and then you were back in 2018, and then we had Nate Stewart, your chief product officer and board member, who was great during the pandemic online.

And so this is the fourth time today. So this is great. So maybe as a quick refresher on Cockroach Labs and CockroachDB: CockroachDB, how you started it, why you started it, what the product does, all those good things. Yeah, so CockroachDB is a relational database. For those of you that don't know what that is, think Oracle's flagship database. That's probably the most famous. IBM DB2, which you'd run on mainframes. Microsoft SQL Server, Postgres, MySQL. So these are all relational databases.

And the key, I think, thing, if you take it one step back, is these are operational databases. So they're the ones that hold all the metadata for your use case. So the items that you have in your inventory, if you're doing inventory management; the balances and the debits and things in accounts, if you're doing some sort of financial services use case. That's what you'd put in the operational database. And you contrast that to an analytical database like Snowflake, or that's probably one of the most common ones, but there's plenty of them.

The reason there's so many databases out there is because everything needs a database. So every single use case in the world has one of these things powering it, and that market's growing very quickly because people are building new use cases. So there's a lot of competition, and there's also a lot of room in the solution space to find the kind of perfect combination of capabilities to push the envelope. And as things are changing very rapidly in the ecosystem, there's a lot of room to improve how operational databases work.

In particular, to use the cloud to really leverage it to make things, like with all products or all infrastructure, we want to make things better in terms of capabilities, faster in terms of how they perform, and cheaper. And we do strive to do all three of those things, some better than others, but it's always a work in progress. Yeah. Do you want to double-click on that history from the relational database of yesterday, Oracle, not to pick on them, to document databases, to NewSQL?

What was the evolution? Yeah, there's lots of different threads that you could weave through the evolution of these systems. I think Oracle, maybe as we start there, they certainly weren't the first of these relational operational databases, but they really did become ascendant through the '90s and the early aughts. And then I think where Cockroach's story really starts is when the World Wide Web came to prominence and all of a sudden there were use cases that were actually bigger than what you might call an enterprise use case, where you had a certain number of customers for a big company.

And all of a sudden you could reach most of the people in the world that had a desktop computer, and then a mobile app of some sort a little bit later. But that actually opened up a gap between what the capabilities of the existing operational databases like Oracle or MySQL could provide for and what the use case demanded. So I was at Google in 2002, and we kind of ran headfirst into this with their AdWords system, which very quickly grew beyond the capacity of a single MySQL instance.

And so they started adding more MySQL instances. They divided the customers between the MySQL instances they had, and then they had to double that and double it again and double it again. And that actually started to create all kinds of other problems. And so Google started to innovate with databases as a result of that. And so they built Bigtable. Bigtable is really, I think, one of the examples you could point to—and nothing's new in computer science—but it was definitely a prominent example that introduced the idea of NoSQL.

So Google actually was very intent on making a very scalable operational database, and Bigtable was their answer to that, their first answer. But the interesting thing about Bigtable is that they went for scale and they dropped all of the things that a relational database had evolved in terms of its capabilities that weren't directly related to just making the thing really, really big. So it didn't have transactions, it didn't have a relational language in which to query with, and it didn't have a lot of these sort of schema management tools that help you manage complexity.

But that was okay because Google just needed something that'd get very, very large. But even two years later, they said, "You know what? We can't build application use cases without transactions." So they built something called Megastore. And then they decided that Megastore was only kind of a half measure and they wanted to redesign from the ground up. And they built something called Spanner. And Spanner is still what Google's building things internally and also providing on GCP. And it's Spanner that really inspired Cockroach.

And to just give you a little bit of the genesis of Cockroach, after 10 years at Google, myself and both my co-founders left to build a private photo-sharing company. So we went from doing mostly infrastructure at Google to thinking, we want to build something for people to use, and particularly for us to use because we didn't like sharing things publicly, but we wanted to share all of our photos when we were on a weekend trip with friends. That was called Viewfinder.

We didn't get product-market fit on it. Snapchat, I think, was the alternative at the time, and I think was probably more in tune with the pulse of the general public than our more sophisticated, I think, but probably overly complicated solution. But we definitely wanted to build the backend for Viewfinder such that it would scale the way Google's infrastructure scaled. And that's where the idea of Cockroach was born, because we realized coming out of Google that those kinds of capabilities that Google had pioneered internally were not available in open source, at least not yet.

And so the idea of Cockroach was born, and we said, "You know what? The Spanner-like capability should be brought to market for everyone else, and certainly as an open-source product." And we didn't build it at Viewfinder because we were trying to build a private photo-sharing application and platform. But we were acquired by Square two years into that journey. And at Square, that's where we saw, you know what, this problem is way bigger than our startup. As some ex-Google engineers, Square was struggling with databases as well.

And we said, if you looked at all the problems Square was having, and they had something like 70 externally facing use cases when we joined them, most of the problems that they were struggling with could have been solved with the use of something like Spanner. So that really brought the idea of Cockroach back into our minds. And we stayed at Square for about 14 months. And then we said, based on the signals we're seeing, and you talk to folks that were working at Dropbox and Pinterest and Yelp, everyone had these kinds of problems.

We said, we do need to follow this dream and this ambition and build a company around it. So that's pretty much when I met you.

So the fundamental premise of CockroachDB is to be the best of all worlds of scalability and transactional reliability. What does the product do today, I guess? Yeah, so that actually kind of brings up a question that some of you might have bugging you in the back of your mind. Why would we call anything CockroachDB? It's not exactly a popular insect. It's really around survivability. And that was one of the key things that we sought to build into the product from the start.

And it was one of the things that motivated Megastore at Google and then Spanner at Google. And this is an idea of like, hey, in the public cloud, things are just different. You have data centers just on the East Coast. You've got many data centers to choose from. They're very close together. And if you can balance data across them, you could lose an entire data center and actually not miss a beat. No postmortems, no running around trying to get things back online, potentially losing data.

The thing can just continue, maybe with a couple seconds of latency. So that was really cool. We built that in. The other big challenge we started out to solve was scale. So we really wanted to be able to support huge use cases, but you don't necessarily know whether your use case is going to be huge. And a great example of that is if you're trying to build a game, right? If you build that with the wrong backend infrastructure that doesn't scale properly, then you're going to run into a success disaster if your game's popular.

And so your thing's just going to fall flat on its face. And re-architecting something like that is not something that you do overnight. So you could really lose the momentum that a game might have in the early stages that you really would like to capitalize on. But I think that's true for any startup as well, any SaaS use case, anything you're building. If you have success in aggregate, your data needs are going to be big. And so Cockroach is really built to scale.

It can start small and can get very, very, very large, much bigger than one of those traditional relational databases I mentioned, like Oracle, for example. Those do have upper limits on how big they can get. But the interesting thing is that those capabilities were really the starting point. And as we've been on this now eight-year journey, we've realized that the architecture supports other really interesting capabilities. When I say the architecture, the right way to think about Cockroach is it's distributed. There's lots of nodes that participate.

That's part of how it gets so big. It's also part of how it can survive. You lose a data center, well, there's other nodes of Cockroach that are running that have some of the redundancy in other data centers, and those can pick up the slack. But we also realized that the companies we were talking to increasingly were multinational companies, or they were even startups, but they very much wanted to entertain customers that might join them or use their massive multiplayer gaming platform from Brazil or from Turkey or from Japan, and you really would like to try to support those more global use cases.

And so we realized, hey, we've got a distributed architecture. We should be able to introduce new capabilities into the operational database to support that. So if you think about something like Twitter or Quora, if someone posts something, you want that to be visible everywhere, and ideally you'd like that to be consistent around the world. At the same time, you might have data that you absolutely do not want replicated all over the world, like you're building a private wealth management system. You definitely want to keep all the data replicated in the user's legal jurisdiction, and balancing those things, those concerns, and having a database fundamentally support them is quite important.

And we'll talk—I know that you're planning to ask me about some other even more recent capabilities of Cockroach—but I think the larger lesson here is just that the work's never done, right? The world's changing very rapidly. Infrastructure has to change as well. And we've just seen over the 25 years I've been trying to solve problems with databases, you improve the state of the art in the database and the application use cases quickly use those capabilities. And then you design the next version of the database, and then the applications use that and want more, and it just goes on and on, sort of an arms race.

Yeah. So let's get into that. So we started talking about this evolution of SQL to NoSQL to NewSQL, a category in which Cockroach arguably falls. So you seem to be going towards this concept of a data cloud, or where does a cloud fit into this? And then the next step after that, which is serverless. But let's talk about the data cloud. You hear a lot about the data cloud these days. I'm not exactly sure what it is.

One observation I'll have about the idea of convergence in data infrastructure is that it's very, very difficult to build a piece of infrastructure that serves as an operational database, just like it's very difficult to build a piece of infrastructure that serves as a data warehouse or a data lake or an analytics system of some sort. In order to be the very best in that, you have to, I think, have a somewhat single-threaded focus in the product category that you're trying to compete in.

Otherwise, you become a jack of all trades and a master of none, I think is the way people put it. And so I see consolidation in some products, but in general, the industry leaders in each product category will continue to have a more narrow focus. But I mentioned before, the cloud is fundamentally changing things and offering incredible opportunities to do things again, faster, better, cheaper, right? The realization that we had is the cloud allows you to get resources almost anywhere programmatically and in seconds or minutes even.

That's a fundamental change from the way the world used to work. And in fact, companies that still do have their own data centers struggle with this problem continuously, which is it can take months to get a new piece of hardware or to find the floor space in your data center to put it in. Anyone that uses the public cloud, which I assume is almost everyone in this room, those concerns seem fairly ancient. But the reality is that's a relatively recent improvement in terms of what the cloud can bring and how you can build on it.

I mentioned before, the public cloud has multiple data centers in single regions and regions all over the planet and over every continent. That's also a fundamentally big change. But also, the public cloud has many other services that you can start to build on. So if everyone here is aware of Snowflake, they're building on the cloud data storage primitives, like S3 or Google Cloud Storage. And that's a huge benefit, by having that primitive, that's allowed them to do things much more efficiently than earlier systems that had to essentially build those kinds of capabilities into their product.

So I think that's the future of things. How can you leverage the cloud and continue to leverage it every time someone else in the ecosystem builds something that could be useful? It's an opportunity. Yep. So everything as a service. We talked about distributed. Do you want to talk about serverless and maybe start with a definition, because not everybody may know what that means? Yes. Serverless is an overloaded term at this point. It was introduced with, I think, like I said, nothing's new in computer science.

So I don't know what the very first usage was, but the one that I became aware of was AWS Lambda. So the right way to think about that is it's a serverless execution layer so that you could actually run your application code in a little snippet, a function basically, that could be called. And you don't have to run a server that has your application logic permanently resident on it, ready to serve queries. Instead, what happens is a query comes in, and it might just be one every week, it might be 100 a second, might be 10,000 a second. Whatever it is, the execution layer that's serverless uses some server capacity somewhere to execute your logic on demand, and it charges you only for what you use.

So that was, I think, the initial introduction for most people of the concept of serverless, and that's at the execution layer. But every execution layer has to deal with data. Otherwise, it's not a very interesting application use case, like a mortgage calculator. It doesn't store any data, right? You put in the little things and it spits something out. That's a very simple application, but virtually every application needs to go hit a database somewhere. And databases are very much seen as being resident somewhere, and that's very true.

There needs to be at least something that is holding the data and making it available. However, a lot of the principles of serverless are applicable to data storage. And in particular, you want to be able to start very small and get very large without having to worry about how many nodes you have, where they are, how big the nodes are, how they have to be upgraded in terms of their operating system, and so forth. In other words, the idea of serverless abstracts you above the concerns of dealing with actual servers and everything that's associated with them.

Also, you really want to be able to pay for exactly what you use and pay as you go. So that's another really amazing feature of serverless, and that of course applies to the database. Or at least it can, and that's something that Cockroach Labs brought to market. And so this idea is just that if you want to store just a tiny bit of data when you start, way less, for example, than you would have the capacity to store if you had just the smallest node possible running your database.

The smallest node that's available on AWS is actually still a potentially way more powerful database, much more capacity than you might need for your use case that doesn't have any users on it yet. Let's say you're a startup and you're trying to work to product-market fit and you release your very first version. You haven't done very much advertising yet or anything. It's just friends and family that are on it. It'd be nice not to pay for a resident VM that's running your database permanently, but that's sort of the non-serverless version of things.

But serverless, if you use literally a single byte of data, that's all you get charged for. And that's an interesting way to start, but then you have a very smooth way to scale up so that you're elastically using exactly what you need. And when we started looking at the problem of doing multiple regions, so we've got users in Western Europe, users in the United States, maybe users East Coast and West Coast are separate because the latency is important, you start to realize that to service all those customers, if you've got a use case like a game, as I mentioned before, that doesn't have many users yet, and you don't really know where they're going to show up, then serverless really becomes obvious as being something that's critically useful.

Because if Australia is not where you have users yet, and there's only 10 users there, you'd like not to be charged for a bunch of resources that are sitting in Australia and not being used. Right. With serverless, you have an ability to have a very large physical CockroachDB cluster, which Cockroach Labs would run. That's available in the cloud, and all of the customers can use that physical infrastructure, but only use a sort of fractional virtual cluster that slices through the physical infrastructure.

So if there's just a tiny bit of usage in Australia, you pay for a tiny bit of usage. If most of your usage is in North America, you can scale as big as you need to there. But again, across the entire global footprint, you're using only the resources that you need, and you're only paying for the resources you use. When did you launch the serverless product? So serverless came out in beta in, I don't know the exact month, but it's been more than a year now.

And we released a general availability version of it in July of this year. So one of your key customers, at least publicly, is Netflix. I think it'd be really interesting to use this as an example. How does a company like Netflix use CockroachDB? Actually, that gets to another interesting point. So we have a number of different flavors of CockroachDB because that's actually been necessary in our evolution as a company. We started off and CockroachDB was something that you ran yourself.

We call that self-hosted because when we got started, that's how most of the bigger customers we had were insisting that they wanted to use databases. These are our operational databases. This is the thinking, right? And this is what we're used to, running these ourselves. This is storing our most valuable sort of crown jewels, the data for our operational use cases. And if we're going to use a new technology, we're going to run it in our sort of information security envelope with the people and the processes that we trust.

And so we had that self-hosted product. We quickly started realizing that there was the kind of new wave, and certainly the future, even for those existing self-hosted customers, was going to be to use a cloud product that was a service that was managed, right? So, in other words, the way that AWS offers their databases to all of their customers. And so we started building that cloud product. And then we started realizing that serverless was going to be an improvement on that.

And we started building the serverless product. So we actually have those at least three broad categories of how our product is offered to customers. And you mentioned Netflix. Netflix is one of these self-hosted customers. That's how they still want to run their databases, but they are moving in the direction of using cloud. So there's going to be sort of a hybrid reality for some time, and I think if you look at the horizon, everything will be cloud. So we do support a very flexible way of deploying CockroachDB.

And Netflix, as you all might imagine, has probably thousands of use cases. I'm not exactly sure how many. I think that's probably accurate, but a lot of things that they offer, and some of those things are massive and some of those things are very small. And CockroachDB is solving a number of different problems for them. I think the most difficult problem, obviously, scale is one, and survivability or business continuity is clearly another. So those are the bread and butter of CockroachDB, but the multi-region is also a major concern, and that's an area where CockroachDB is quite differentiated in the market.

And so they've already, I think they gave a recent talk, which is on YouTube, so this is not any kind of private information, but they have hundreds of Cockroach clusters already. So you can just see how quickly the usage of this can increase within an organization that has a lot of use cases that need these capabilities. And building on this point of self-hosted to cloud to serverless, if you were going to start a database company today, would you go directly to the cloud as the market evolved that way?

That's a really good question. I think maybe not, but my God, if you thought about having to build all the things that we've built over eight years, I don't know if I'd want to start the company. The reason I say it would be hard to imagine just going straight to serverless, although that would be the only way that you could think about doing it for the reason I just mentioned, but the reason that would be difficult is, well, there's a lot of competition if that's the only way that you run.

If you want to win, at least in 2022, the Global 2000 as customers, you really do have to have a product that runs in a variety of different configurations because people are, I think, reasonably hesitant to adopt a solution that only works in a single fashion. So, I mean, I'm not saying it's not possible. I agree with you. We'd probably go directly to serverless if we were starting today. But I'm glad we don't have to make that choice because the fact that we run in as many different configurations as we do is extremely appealing to the high end of the market, which is, I think, where also the differentiators I mentioned—scale, resilience, multi-region—those are incredibly important differentiators to the high end of the market, a little less to the low end.

Although you do see in the emerging companies that are going to become part of the Fortune 500 in the next five years, five to 10 years, many of them do have those kinds of use cases. So we have a nice distribution of companies across those two segments, but the world's biggest companies are prime candidates for our software. And at the very beginning, and I guess still today, you were a very successful open source company. Do you think the world has evolved as well?

There was a time everybody hated open source as a business model, and then it switched to everybody loved open source and open source was the only way. Do you think that has evolved? Yeah, unquestionably it's evolved. So when we started, we adopted what's called the open core business model. So the idea here is that you have an open source product that drives really broad adoption, so you get some level of ubiquity. Many, many, many people are using it because, hey, it's open source, it's very, very easy to download, to work with, you're not paying upfront for the software, you may eventually pay for support.

That was sort of the Red Hat model for open source, but the idea with the open core model is that the open source product would just be the core, and what you do is when you started getting that ubiquitous adoption, you start to introduce enterprise features, which would be a different license. Most people would adopt with the core and then you'd upsell them to the constellation of enterprise features that essentially form the basis of your enterprise offering, let's say. That business model, I think, lasted about four or five years.

When we started the company, it was, I think, a good bet that that was the right way for us to do it. And we operated under that until it started to become clear that open source business models were under threat, in particular from some of AWS's actions. So they really went after Elasticsearch. That was one that they, I think, changed the nature of the open source business model and made it less likely that you'd succeed.

And what Amazon did is they said, we can repackage the open core, put our own enterprise things around it, and most of the work's already been done for us to create this piece of software, and we're going to repackage it. And with that, in addition to the incumbent cloud platform, means that we're going to be able to get huge numbers of customers just because everything's integrated. It's all part of the same billing system, all the identity and access management works together.

So you have all the advantages of the cloud platform combined with the quality of the open source offering. So as soon as people started to wrestle with that, the open core model became less tenable. And interestingly, at that exact same time, the idea of really offering things as a service in the cloud first and foremost and worrying a little less about open source was also quite ascendant. Again, because of Amazon, I think, more than any company. So they offered both the twilight of one business model and really ushered in the future there.

And I do think that if you think about the progression here, you had closed-source software, open-source software, and then, let's say, cloud services. They make sense because they're moving along a gradient of essentially less cost, right? And the cost isn't always measured easily in dollars and cents. It could even be measured in time, for example, time to value, and the resources required to run something in production. So you went from closed-source software, which was incredibly expensive to actually buy it and to use it because you actually had to go through procurement.

So you'd talk to some salesperson that might have a relatively long process, and you have to go through legal wrangling, go through procurement, and eventually they send you a bunch of printed manuals. And there wasn't really a community necessarily that was online, but this is just the dominant mode of how software was purchased. And you can see why that was so ripe for disruption. And when open source came along, it was very easy to both get that community to very rapidly try out the software, to run with it.

You didn't actually pay for the software upfront. Of course, you paid for the hardware and so forth. The idea of services actually takes that a step further, not because the idea is free—that was one of the nice things about open source—but because the process of actually running the software is no longer something you have to learn how to do. So the time to value and the sort of day-one-plus operations is something that was respectively decreased on both dimensions, right?

So I think what we see with serverless and our serverless offering, for example, is free. So it's a perpetually free relational database cluster up to a certain threshold of utilization. And so it's kind of like what we think is available in sort of this next generation of value proposition for infrastructure is that you can both acquire the software very rapidly because it's just a service, you don't have to learn how to run it. There's even a free tier, which is at least as free as open source was in the sense that you always had to pay for the hardware with open source and the support.

So I think that same idea, you have the pass-through costs to the cloud and you also have the support. So it's kind of like what you're moving along there is just less resources required to successfully implement a use case using infrastructure that's available. So it's kind of like open source ate the software world. And now I think cloud services are very much cannibalizing the open source business model. And that's not to say that open source is going away. I don't believe that's true.

Not true at all. So you'd still recommend open source as a strategy for most enterprise software? It's a good question because people ask me that all the time when they're doing startups: should we open source this or not? And I think the answer is: are the other core benefits of open source really important to that community? Because sometimes they are. I'd say it'd be hard to imagine a relational database at this point that isn't open source, but that might be the case.

I do think that you really just need to look at what's the best way to deliver value to the customer, and I think that that can be done quite easily without open-sourcing code. And so the mandate to open source is not nearly as strong as it was when we started Cockroach. Maybe last question or theme from me, because then I want to open up for questions. What are some lessons learned on the go-to-market side, particularly in light of the three of you founders being super deeply technical people who had to learn a lot of the go-to-market in a context of a shifting environment from open source to cloud and all the things?

But so, how did you start? How did you get the first customers? What worked? What didn't? And then as you evolve towards more of a sales organization, when did you do it? Why did you do it? How did you do it? That's a good question. When we started Cockroach Labs, I realized that we'd probably be an enterprise software company, and that made me very nervous because I'd never really dealt with that problem before. I'd built software at Google, for example, for Google engineers, and that was sort of more of the mental model I was comfortable with.

And the idea of having potentially hundreds or thousands of customers that needed to be supported was something I had to get my head wrapped around. I will say that it's very easy when you're the sort of chief technical evangelist to go and talk to customers, and something you should do very early and often, and try to find those design partners. It's very hard, though, to sell, especially to a larger organization. I quickly realized that the gulf between being able to get somebody very interested in your software and actually getting an MSA and a signed contract and money in the door was not something that I was going to cross on my own.

And so we hired our first account executive and SE pair, and I watched how these two went after some of the customers that were interested in Cockroach. And actually, can we double-click just on that piece? Because that's a question that comes up all the time. You're a young startup, you're very technical founders. Who's your first AE? Are they young with high slope? Are they experienced? Who are they? It's an interesting profile. You definitely don't want somebody that has been working at a scaled organization.

And really understands how to manage sales folks, scale the team, expects marketing to have a certain amount of leads inbound, and so forth. In those early stages, you need somebody that specializes really in an exploratory sales motion because you don't know how much you can charge for your software yet. You certainly don't know what kind of messaging is going to work, who your ideal customer looks like. You're trying to figure these things out, so you need somebody that can go into any customer and really just listen.

I mean, to be fair, that's always what you should be doing in a sales motion, but I think some people are really geared towards listening, with their ears perking up when someone mentions something that just might have something to do with your product, right? Because you just don't know exactly what that motion looks like yet, and you have to figure it out. And there's a lot of things that could be right. So there is a certain kind of early sales leader that specializes in that.

But as soon as that person starts to figure out what that motion looks like, you're probably going to need to replace them because the person that can figure that out is not usually the person that can mentor other salespeople and start to scale an organization and really codify that motion into something that can be taught through enablement to a larger sales organization. And then fast-forward to today, you have more of a top-down, sales-led kind of motion, or do you still get juice from the community and some bottoms-up inbound?

What does it look like at scale? Yeah, it's a combination of a lot of different things. We definitely still get open-source lift, which is interesting. We get it through increasingly a product-led growth motion with our serverless platform, and we're extending some of the principles of product-led growth even to upmarket in terms of, for example, how is the product experience? Let's say a really big Fortune 10 bank is betting on your product strategically and it's being rolled out within the bank.

You want all the individual teams in that organization to experience the benefits of a product-led growth motion. And so those principles apply. If it's all top-down and sales-led, it's very hard to scale or very expensive to scale. So you do want to balance those, but it depends on your use case. With CockroachDB, and probably any database that's operational, it's a solution sale. It's very involved. There's multiple stakeholders. It's kind of a double-edged sword, right? It can be very difficult to get past all the hurdles and all the technical evaluations and even the contracts and things, because this is a very important part of the stack.

If it goes down, everything goes down, right? So the contracts become more fraught as a result. So you do need to have the right kind of sales organization to accomplish that sale. And I'll just say that in the go-to-market, maybe the most counterintuitive learning that I've had—and it should give people that are on this journey maybe a little bit of an optimistic perspective—is that you'd think that when something does go wrong with your operational database, that customer is not going to be happy at all.

In fact, they might churn on you because you failed them in a very critical thing, and Cockroach is not supposed to go down. So I think, at first blush, a failure with your operational database means you're going to churn a customer. In fact, that's not true. You're actually more likely to churn a customer if they never have a problem with your software, because they look at it and are like, why aren't we just using the open-source version of this?

There's nothing that's wrong with this. We don't need support. What are we paying all this money for? This is a very expensive line item. And what we found is that when—not that we encourage things to go down by any means—

We take every customer's problem as our failure and work around the clock to fix them. But when you do have a problem, the right way to look at it is it's an opportunity. It's an opportunity to build substantial trust with the customer. If they see that you are partnering with them at the level that their issue is your top concern, just like it's their top concern, then that actually sets you up for a very long relationship with trust and also a huge opportunity for expansion because you're now seen as a partner that they can rely on for the long term.

They say that all of these crises are opportunities. And I think with infrastructure, at the very least, which is what I've had my head in for the last eight years, this is absolutely true. So it's not that you ever welcome a failure, but you want to put all your energy behind solving it. To support a customer in that scenario, what did you do, and what do you do? Do you take your engineers and assign them, or do you have a customer success team that's deeply technical?

Who does this, and how does it work, and who do they report to in the organization? Well, obviously, like all things, this evolves. Just like I mentioned, that exploratory sales leader, which then evolves into somebody that can scale the organization and run the enablement, the customer success side of the story also evolves. At the beginning, it's literally the database engineers, at least in our case, that are working on these things because we didn't have a customer success team. But wow, that's pretty interesting customer success, right?

I mean, certainly if something goes wrong with Oracle, you don't have the chief Oracle database engineer working day and night on your problem. If you did, it would probably get fixed more definitively. So it's kind of like, that's something that you can actually bring into the early sales conversations. Like, well, you are extremely important to us as a customer. You're a partner. You're going to influence our roadmap, and we care more about your problems than any other vendor is ever going to.

Right. So you can actually sell that. So in the early days, it really was, including me, everyone would be on these problems, and we'd be working to solve them. But then you hire your first customer success—your first actually was technical support that we hired first, then customer success. And in terms of escalations, you have to be careful as you get bigger how you do that. You want, I think, to continue to have your engineers that know the product better than anyone available when an escalation demands it.

You also want to create a little bit of a wall so that they don't get distracted to the point where they can't do their work on the roadmap, which is also incredibly important. So there's a balance there, and ultimately what you want to do is increasingly push solutions into knowledge bases and into the product itself, in terms of observability in particular. You want to see that there are classes of errors that you start to recognize, or problems that customers have, where first you can get your technical support and customer success folks to do what before you needed engineers to do, because now they have tools internally where they can actually see some of the things much more clearly than they previously were able to, because you're actually saying, this is a class of problems that we can surface very transparently if we build this new thing into the dashboard.

So that's great. And eventually you want to push that so that the customer can easily diagnose their problems and has ways to fix it that they understand. And eventually you want to make it so that you eliminate classes of problems. And maybe you're trying to do all of those at once to some extent, but you get better and better at that cycle. But that's part of—it's one of the really chief inputs in any product development cycle. It's not just the new capabilities, but it's how do you make the product more and more bulletproof and observable.

All right, on that note, that's a wrap for today. Thank you so much for sharing all of this from a tech perspective, market perspective, go-to-market perspective. Super great. I hope you come back soon for a fifth time. It's my pleasure, Matt. Thank you.