While we miss the special energy of having 350+ people in a room every month, it’s been fun to settle into the routine of hosting the online version of Data Driven NYC — our 19,000 person community focused on all things data, AI/ML and enterprise software. Our events are free and open to all, and having them online has enabled many more folks around the world to attend them live – to the point that my co-organizer Jack Cohen and I have been mulling renaming the event “Data Driven Global”.
At the most recent event a few days ago, we had the pleasure of hosting Nate Stewart, Chief Product Officer, and newly appointed Board Member, at Cockroach Labs.
Cockroach is an exciting, fast-growing startup. Named to the 2020 “Future Unicorn” list by CB Insights and Fast Company, it is the company behind CockroachDB, a distributed database with standard SQL for cloud applications. The company has raised $195m to date, from a long list of great investors such as Benchmark, GV, Index, Redpoint, Altimeter, Tiger, Bond, Work Bench – and our firm FirstMark, since the very first round of funding.
We covered a bunch of interesting topics with Nate, including:
- The role of a CPO (and product organization in general) in an open-source database company like Cockroach
- A quick history of databases, and where CockroachDB fits in
- Building a cloud product on top of an open source project
- Some great thoughts on diversity in tech
Here’s the video, and the full transcript is below.
FULL TRANSCRIPT (lightly edited for clarity and brevity)
Nate, welcome. You are the chief product officer at Cockroach Labs and you also just became a board member of the company, which was just announced on July 15th, which is a very big deal. So congratulations on that.
I’d love to start with a little bit about you and what was your path into the company?
Lovely. And Matt, thanks so much for having me on the fireside chat. So my background spans engineering and business. I started off as an engineer building financial software at Bloomberg. I looked at our LinkedIn. I see we actually overlapped there. After a couple years, I realized that I was more interested in the why behind the products we were building as opposed to the how or the application details. So I went to business school to try to find a path into product. And ultimately, I ended up at Microsoft in their cloud and enterprise group at a really interesting time because this was 2013/2014, around the time that Microsoft was saying, “Hey, we’re going to go all in on the cloud,” and it was also the time where Satya was starting to take the reins from Steve Ballmer and thinking about, what does it mean to be cloud first and what are some of the cultural changes that have to be in place to pull that off? So that was definitely a foundation for some of the work that I’m doing now.
After that, I spent a couple years doing SaaS startups, leading increasingly large product management teams, and then took some time off to figure out what was next. I didn’t know if I was going to start my own company or try to join as head of product at a small series-A-style company. And that’s really where I came across Cockroach Labs. I had a chance to meet Spencer Kimball, the CEO and co-founder, and I just fell in love with the vision and the team and the opportunity because I think this is a once-in-a-generation technology that I can talk about in a little bit, but that was my path to Cockroach and I joined as Head of Product. That was pre-revenue, pre-CockroachDB. I’ve spent the last three years trying to figure out, what’s the right shape of Cockroach to make it that post-Oracle database?
Thank you. I think it’d be really interesting for the audience, in a somewhat educational way, to talk about your role. What does that actually mean, chief product officer at a database company? What’s your role? What are your responsibilities?
So I’m responsible for a few things. The first thing is the product strategy. What are the investments that we’re going to take on? What are the opportunities that we’re going to pause on in order to build our competitive advantage? So fend off Amazon and some of our other competitors, while also attacking this cloud-native SQL market. The other big thing I do is professionalize the process of innovating and taking innovations to market. So building out a predictable way to take inputs from our field and from our customers and translate that into outputs in the form of a prioritized roadmap, the way the product managers work with the engineering team and how they enable the broader team to take those innovations to market. So the black box that translates those inputs to outputs is really where I spend my time. It really comes down to the people that make up the product team, which is the product managers, the design team, and the education team, how they’re organized and what are those routines for, again, predictably going from input to that prioritized output, which over time should lead to a successful business.
Who’s in your team, for example? What are the roles? How does a product organization look like in a company of your stage?
The product team right now is about 25 people. So there are about eight product managers. There are the four leads and they’re generally organized around user journeys or jobs to be done. This is not an obvious organization for a PM team at a database company. It’s much easier to be organized around layers of the architecture on its code, but similar to the last talk, we’re talking about how can we deliver value consistently and how can we organize the PMs around particular customer pain points? So what’s involved in running a query? What’s involved in observing that query and understanding if it’s slow or not versus what’s involved in recovering from a disaster? So those are some of the ways we organize the product management team.
So you’re saying that’s unusual in a database company to be organized that way? I guess, as a related thought, I guess, problems are never solved, but once a problem gets solved, does that team get disbanded and then they move on to the next problem?
No when we organize the product team, it’s really around the product areas which are collections of problems to be solved. One problem may be queries are too slow. So we can solve that by making some changes at the storage layer. We can solve that by thinking about our query optimizer, our cost-based optimizer, how that performs in different environments. So we never run out of problems to solve for a particular product area or set of user journeys, but that is one of the reasons we organize that way because, if we organize by a feature, features can certainly be done, but if you have categories of problems, ideally, they’re longer running problems.
One last question on this topic. How do you recruit people? What do you look for? What makes a good product manager?
Yeah. That’s a great question because my path to product management leadership has really taken place over the last few years in the New York ecosystem, where there are not that many classically trained … I don’t know if there are any product managers that are classically trained, but there have not been any experienced product managers. So I really had to build a capability around identifying potential, whether it’s great leadership potential or great communicators or people from, say, a customer success organization that really had the empathy for the customers in figuring out, how do I build programs to help close those gaps?
So to date, I’ve really focused on those things. It’s the communication, the leadership, the customer empathy. And then I focused on, all right, how can we help people understand the core problems? How can we help them understand how to work with engineer and design and understand what is the role their product plays in enabling the broader organization? But those are skills that are easier to close than some of the other ones that I mentioned. And it also gives me a personal advantage in hiring because I can hire product managers a lot faster than someone that says, “Hey, you already have to be a product manager or you have to have a computer science background.” So I think that’s a personal competitive advantage.
Switching to the product, itself, especially for people who have never been exposed to Cockroach, what is CockroachDB and what is the fundamental value proposition?
CockroachDB is a SQL database and it makes it really easy to build resilient, scalable, and low-latency applications and services. And one of the things that makes this database so special is that it really makes it possible to build the types of applications and the types of architectures that you’d see coming out of an Amazon or a Microsoft or a Google, but it makes that technology available to every developer. Now any developer can build a multi-region application or a global application. And when we think about the major value propositions for Cockroach, we bucket it, typically, into three categories. So there’s the resilience aspect. Right? So how do I build an always-on application and how do I have a database that can survive failures, whether they’re planned or unplanned. An unplanned failure in the cloud could be a virtual machine restarting, which would result in downtime in a traditional database, or it could be a data center going down or a region going down. But there’s also planned downtime, which is a pain in the neck for relational databases, like, “Okay. Hey, I want to upgrade my database or I want to do a schema change.” And traditional relational databases, you’re going to have to take the app offline and you’re going to have to lock a table. And that is, really, no fun for the developers and the operators.
The other big value proposition is around scalability, specifically horizontal scalability. This is something where people say, “Hey, Cockroach is a little bit of a traditional relational database, a little bit of a no-SQL database.” I like to think of it as an evolution. So what would a relational database look like if it was built with the cloud in mind? What the scalability aspect means is that, instead of having to scale up if you want to scale your writes to reads, you can just add more commodity machines to this pool of nodes. And from the point of view of the application developer, they don’t have to worry about how many nodes there are. From the point of view of the application developer, it looks like they’re talking to a single Postgres database, but it just so happens to be elastically scalable. So it’s a really nice abstraction for developers.
And then the last big thing that I’ll cover for the value proposition is this idea of locality or data placement. So with Cockroach, again, instead of having one machine, you have many machines, but you can spread those machines around a country or around the world and you can create policies that say, “Hey, for a particular user, I want their data to be physically close to them so, when they’re making requests, they have a local experience, even if I have a global cluster.” And we see, in practice, our customers using this functionality for a few things. One, of course, is performance. The other is our resiliency. So I talked about resiliency, but by spreading data physically far apart, if a machine goes down, you can survive it. But one that is particularly timely is everything around data privacy and data domiciling. How do you make sure that a particular record complies with whatever the law of the land is? So those are some of the fundamental value props of CockroachDB.
Great. And you sort of were alluding to this a little bit. I’d love to double click, especially for people that don’t necessarily spend a lot of time in the world of databases. Could you maybe sort of go back in time and do sort of a quick evolution of the database world, leading to the punchline of why does the world need another database like Cockroach?
Yeah. So let’s start with the relational database. And the relational databases, they were built in the ’70s. Eventually, SQL came along, which was a really, I’m not going to say an intuitive, but a very powerful way to interact with the database. And from the ’70s to, say, the web 2.0 era, the way these databases worked was that, if you wanted to add more capacity, if you wanted to support more throughput, you’d have to scale them up and that was very expensive. But one of the powerful things about running everything on a single machine is you could provide very specific guarantees that made developers’ lives easier, specifically transactions, which is a big deal. If you want a series of operations to either all happen or all not happen, a classic example is doing a balance transfer or processing a payment, you want those guarantees to be in place.
What started to happen is that, as more databases were experiencing more traffic, web scale became a thing, people started saying, “Hey, we really can’t scale up these databases anymore. It’s not cost effective. And we’re also running into resiliency issues. In the cloud, machines start up and spin down all the time, so we need to figure out a way to move to a more distributed architecture.” Unfortunately, this is the no-SQL movement. What that meant was they had to give up SQL. They couldn’t figure out how to make SQL work. They couldn’t figure out how to make distributed transactions work. That’s very hard to do when you don’t have that central coordinator. At least they couldn’t figure out how to do it in a way that maintained that high performance, but that was a trade-off that they were willing to make.
Fast forward a couple years to what I say is more of a cloud-native era, people are realizing, “We actually did need transactions. And you know what? SQL is pretty powerful,” because one thing that I personally experienced is that, either way, you’re going to build the database. Either way, you’re going to build the transaction. The question is, are the developers going to do it in the application tier or are you going to let the database do its job? And so, fortunately, with some breakthroughs in computer science, there was the Google Spanner paper that came out and it said, “Hey, you can get transactions. You can have these types of guarantees in a distributed environment,” and that was really the foundation for the work that we’re doing at Cockroach Labs with CockroachDB.
And so we think that, again, if you were to build a relational database today with the current state of the art, you would end up with a shared nothing, a SQL database that supports transaction so developers can focus on code without having to reason about correctness and if a database is up or down or when it’s available or not available.
It’s very exciting because it’s obviously such a massive opportunity. At the same time you’re, as always, competing with some big projects and then very large companies. How do you position against other databases or, in particular, Amazon or Cassandra or that category of databases?
It comes down to trade-offs. So for Amazon Aurora, that’s a great product, depending on what you’re trying to do. They made a different set of trade-offs than we made. So Amazon Aurora is really Amazon Aurora Postgres or Amazon Aurora MySQL. They started with the Postgres execution engine or the MySQL execution engine and then they just rewrote the storage engine to be cloud-native. And so the pros of that is that, if you already have a Postgres application or a MySQL application, you can migrate back to Aurora very quickly. The cons are that if you’re writing and if you have a lot of writes, they’re still going to a single master. They didn’t rewrite that execution engine. So if that master goes down, your app is offline. If you want to scale your writes, you’re going to have to get a larger and larger master machine.
So if we think about the types of customers that start to come to CockroachDB after Aurora, it’s usually because their machines are too big, they’re too expensive, or because they’re seeing downtime when that master goes down. So that’s how we positioned against Amazon Aurora because what we’ve done with Cockroach is we’ve said, “Hey, we’re going to rebuild the database from the ground up with the cloud in mind. We’re not going to stop at the storage layer. We’re going to go all the way to the execution engine.” And so what that means is we don’t have full Postgres compatibility today, but every Postgres feature we have is cloud-native and will use the full power of the cluster to serve your queries and we can scale writes arbitrarily, we can scale reads arbitrarily. And of course, we can do that with much better resilience than you’d see with Aurora. But again, it’s trade-offs.
Same thing with Cassandra, but it’s a different set of trade-offs, in this case. So now you’re talking about no-SQL and SQL. Cassandra can give you extremely fast reads, but it’s going to come at the cost of some flexibility because, for Cassandra, you have to know your query patterns ahead of time. You have to design your data for a particular set of queries. That’s fine if it’s an existing app and you know exactly how it’s going to be used, but that really ties your hand if you’re trying to solve a new type of problem. And of course, there’s an issue with correctness. So if you need transactions, if you want all of your data to tie out, that becomes an issue that you don’t have with Cockroach.
An example of where we see people going from Cassandra to Cockroach, there was a distributed backup and restore customer that we’re still working with. They were using Cassandra to handle all of the metadata for their backups and they found that this is a human generated metadata, this is machine generated metadata, and quite often, this metadata would get out of sync and the files would get corrupted because it didn’t have transactions. They needed the scale, they gave up on the transactions and it ended up being a huge headache for their operations team and for their customers. So, they moved to Cockroach and they don’t have to worry about those issues anymore. So, it’s trade-offs. You can see customers using Cockroach and Aurora or Cockroach and Cassandra. There’s no wrong answer. It really depends on your workload and what you’re optimizing for.
So, as another series of questions, Cockroach is one of those great enterprise software companies that’s built in a modern way. Meaning that it still very much is an open source project. There was an enterprise version of the product, and now you have a managed offering, which is called Cockroach Cloud. I’d love to talk about those various points, I have several questions. One is at this stage, now that you have an enterprise product and managed offering, what do you do with the open source project? Is that something that continues to create value in terms of the sort of testing out the products and giving you ideas? How do you think about community? How do you think about the pure open source part of what you do these days?
The open source business is very important for us, or at least the community is very important for us because it’s one of the ways that we improve the efficiency of our enterprise sales. So, one of the things we measure when we’re looking at enterprise sales is what percentage of opportunities have already at least evaluated Cockroach to be, if not, are already running a production by the time our sales team reaches out and the open source product is one of the ways that we support that. So, yes, it doesn’t have all of the enterprise features, but you can go a long way with just that open source product. So, that’s really important. Even for the enterprise features, the source code is still available. It’s under a different license, but you can still see how everything works under the hood, and this has been really important as we’ve started to approach more sophisticated customers. So, some of the streaming companies are the same day delivery services that are using Cockroach. Oftentimes they’ll say, “Hey, you have great docs. We understand how your resilience model works, but you want to dig a little bit deeper. How exactly does this feature work?” And our engineers can point them to the code. They can read it. They can get comfortable with how it works and then they’re more confident when they’re going into production.
The last thing to cover is Cockroach Cloud, which we believe will be the default way that people experience CockroachDB, because this, again, lets developers focus on building applications while we handle all of the operations. This is important for a few reasons. One is that it lets us bring, and this is on the roadmap, but it lets us bring the price point down for some of those global deployments to a level that we wouldn’t be able to do if people were running their own clusters because we can start to take advantage of a shared architecture. So, thinking about how do we deliver CockroachDB in a serverless form factor where you don’t worry about machines, you don’t worry about paying for pre-provision resources. You pay for exactly what you use.
Cockroach Cloud really removes all barriers between developers and our value proposition. And one of the things that’s been particularly exciting about Cockroach Cloud is that when we first built it, we were thinking, “Hey, this is for the startups. This is for the growth stage companies.” But what we’ve seen in practice is that even the enterprises are like, “We cannot hire site reliability engineers or operators fast enough to run these types of clusters. Cockroach, can you run it for us? Can we leverage that Cockroach Cloud?” So, we’re trying to keep up with the enterprise feature stack, but we already have a couple of really exciting, customers running a Cockroach Cloud in production.
There’s one other quick thing to say about Cockroach Cloud, which kind of blends the Cockroach Cloud with the self-hosted product is that we also see that Cockroach Cloud is giving us a chance to not only ‘ruggedize’ a product because we’re running the Cockroach DB at scale. It also lets us take what we’re learning and share that back with our enterprise customers that are running in their own environment. So, we can share the reference architectures, how do you do multi-region Kubernetes? The best practices and even some of the tooling we’re providing so self-hosted customers can run their own clusters at scale.
I’d love to talk about the journey of building something like Cockroach Cloud for anybody in the audience that is starting an enterprise software company and is starting with open source and says, “Yeah, at one point we’ll monetize, we’ll buy a building, own a cloud product.” Any lessons learned – the good, the bad, the ugly of building something like that.
Yeah, there are a couple big lessons. The first is that this idea of running a managed service ourselves was not an obvious one. First principles we knew we wanted to remove barriers between developers and our value proposition, but we also could have done that with partnerships and licensing. We could have let other people run Cockroach to the surface and built the business that way and just focus on the core database. So, that was a choice, and we decided to go more for a vertical integration just so we could get that hands-on experience running the database. So we get those learnings and start to feed that back into our product and our community. That was one of the reasons we went with vertically integrated. The other aspect was the data and understanding our customers. We don’t look at the data that is in the database, but where are people getting stuck when they’re signing up? How long has it taken them to run that first query? That’s information that was completely lost to us when we were just offering the open source and the enterprise product.
The other big challenge here is a cultural one. If you think about what strategy you want to have as a business, what features you want to build, you have to think about what’s the market that doesn’t make sense to build? Is it going to be profitable? But what are our capabilities as an organization? Can we pull this off both from the skills we have, but also from the culture we have? And so going to the SaaS product, that’s a mindset shift. We’re shipping a database once every six months, and now we’re moving into the SaaS model where we have to look at data, we’re getting to the point where we’re AB testing, doing some of these more sophisticated things at different levels. Even just understanding what that funnel is and how to manage against that and say, “Hey, we’re were never really a waterfall shop but now we’re really agile. Okay, what we thought we were going to do a month from now based off of how many people are falling off and it’s time to add a credit card, we’re going to have to change that flow.” So, that was a culture that we had to install and start to add to the team in order to pull this off.
Another area that I think is pretty interesting for people to learn about is how do you win the hearts and minds of developers. It’s a very different type of audience. So, what are some lessons to learn there?
The way that we’ve been approaching this is helping developers do things that they couldn’t do before and helping them do that and faster. I talk a lot about the global applications. That’s very difficult to do if you’re a small team. It’s very difficult to do if you’re a large team, and removing that burden and letting them build those FANG style experiences in their applications, whether it’s a startup or a Fortune 500 that may not have the same engineering capabilities, that’s something that helps a lot. The other thing that we’re looking at, specifically focusing on the time to value, is Postgres compatibility. And so, right now I’d say we have practical compatibility for most of the features that developers want. We do support it, but we don’t have perfect compatibility, and what that means is there are certain features and certain familiar tools in the Postgres interface that are in the Postgres ecosystem that developers are used to using. Like, “Hey, this is my stack. This is the ID I like to use. This specific GraphQL library I like to use. Why does that work out of the box with Cockroach?”
They can make it work the different workarounds, but that’s friction that doesn’t have to be there. So, we really do look at Postgres compatibility, and of course rebuilding it to work natively in those cloud environments. So, those are some of the things that we’re doing when it comes to winning the hearts and minds of developers.
They also, fully use fantastic content, and you’re sort of a university as well. Academy or whatever it’s called, but like a training consultant.
Cockroach University. Our goal is to train as many developers as possible. So, this is something that we’re doing for awareness, but it’s also something we’re doing for self-sufficiency. Tight now we have a Getting Started With a Cockroach DB course, and we’re in the process of building our How To Build a CockroachDB App Using Python course. And so we’re starting to get really prescriptive on how to get the most out of Cockroach as a developer, and this is a team that we’re really starting to build out. We believe that online education really is the future way that we’re going to get CockroachDB into more mission critical applications, again, in a way that our sales team doesn’t have to be the first call. And so, that is another way that we’re generating developer love, or at least awareness and engagement.
Before we get into questions, I’d love to just completely change tacks to a completely different topic. I’d love to talk about which is diversity and inclusion in tech, which obviously is an extraordinarily important topic, and interestingly, it feels like it’s really a moment happening now. I guess I’d love to hear your experience, your thoughts. My biggest question is like, how do we not blow it? How do we not capitalize on the energy, which is very palpable in at least in my little corner of the world in startups where like people really want things to change, but don’t really know what to do or how to do it. Any thoughts that you have, I’d love to hear.
This is something we’ve thought a lot about at Cockroach Labs. It’s something I think a lot about personally. One area is just accountability and transparency. Everyone posted black squares after the murder of George Floyd and they said, “Hey, here is how we’re going to change, here are the programs, here are the donations we’re going to do.” All right, a month and a half later, two months later, where are those programs? How are they doing? What are your diversity numbers? Have you put anything in place? That’s the first step to me. The second thing is realizing that it’s not going to be easy, because one thing that we’ve seen is, “Hey, okay, these programs sound great and really easy to put in your OKR. We’re going to spin up a rotation program or we’re going to do certain things.” Like, “Oh, wow, it’s actually hard to, to build this pipeline.” And then you say, “Oh, it’s a pipeline problem.” Well, you can build your own pipeline, and one of the ways that we’re doing this at Cockroach labs is really looking at those requirements.
I talk about what are the requirements to be a product manager? Do you have to already be a product manager? Do you have to have a computer science background, or can we add some flexibility? Can we take on the burden of educating people that come from non-traditional backgrounds and putting them into a position to succeed? The other thing that has been really important at Cockroach Labs is just looking at every step of the process and understanding where bias can creep in. Not looking at the names, or not looking at resumes in general for the interview panel. Looking at salary bands. So, not giving advantage to people who know how to negotiate better, making sure there is there’s pay equity across the board.
The last thing I’ll say is inclusion is important. So, if you have a diverse team and it’s not inclusive, you’re not going to get the benefits of those diverse points of view. One of the benefits of diverse points of view is, of course, you get better products, more creativity, but you just get a better sense of truth. One of the ways product teams fail is if they get out of touch with reality and groupthink is a great way to get out of touch with reality. So, what are the ways that you can build an inclusive organization? It comes down to the language you use, some of the routines you have. For example, at Cockroach Labs, some things that we’ve done on the docs team is we’ve updated the style guide to use more inclusive language, to not use ablest language or language that is unnecessarily gendered. Those are some of the things we’ve done. On the design side, we have our personas. So, who are the types of customers that use Cockroach? We have illustrations for each of those personas. Initially they weren’t very inclusive. They didn’t reflect our customer base or our community. So, we redid those. It’s small things, but they add up over time in terms of making an inclusive environment where you can get the benefit of diversity.
That was a terrific answer. Lots to think through. Very cool. All right. I want to give a chance to people to ask questions –
Great conversation so far guys. So, thanks for that. A couple of questions in the chat. The first one, how do you manage the tension between managing open source communities/project and commercializing it? And at the same time, how do you prevent large cloud providers from launching their own products, leveraging open source?
Yeah, that’s a great question. So, the answer to the first one is we started off with an open core approach. So, we have a generously licensed core version. That’s the open source version, which at the time was Apache 2.0 license, and then we had enterprise features which were licensed with a Cockroach community license. This came down to segmentation. So, the goal was to say, “For the open source product, we want that to contain everything a startup or a new company would need to be successful and to run in production.” We’re okay giving up some revenue to support adoption. So, we’re super generous with that free tier. Then for the enterprise version, it’s like what are the features that startups really don’t care about, or the average developer doesn’t care about, but a large bank would value a lot? Those are the features we tend to put in that enterprise skewer, that enterprise license. So, that’s the framework that we’ve used to support a wide or a large community while also monetizing people who do have that ability to pay it.
To answer the second part of the question around how do we prevent a large cloud providers from using our technology? We do that in a couple of ways. So, the most, none of these are the most important one, but one of the big things we did is we did change our open source license. So, it’s still source available. It’s still free, but we moved from Apache to a license called the business source license, which is just like Apache you can use the software, you can redistribute it, you can make copies, you can sell those services around it, you just can’t offer it as a commercial database as a service, unless you buy a license from Cockroach. The important thing about that license, the BSL is that it has an additional term, which says after a certain amount of time, the BSL code reverts to the Apache code. So, in our case, after three years from a release, the BSL code will become truly open source. So, no matter what happens, we’re going to leave a very strong, open source legacy, but the code that a cloud provider would be able to host would be three years behind what we’re doing.
So, that’s an important bit of protection, but we’re not going to bank on that. It’s nice to have. It prevents us from doing weird things like saying, “Oh, we don’t want to make this feature open source. We’re going to start putting more stuff in the enterprise license, because we’re worried about Amazon. This lets us still say, Hey, this is going to be very generous, but we don’t have to worry about Amazon using that functionality. But the other thing we’re doing is investing in Cockroach Cloud. We have the expertise around how this database works. We understand how to run it at scale, and we are going to be the experts at running Cockroach DB, and we can focus on building an experience that’s 10x better than what a major cloud provider could do just because we have such a tight relationship between the operators and the site reliability engineers and the engineers that are building that database.
If you were to rewind the clock five years and you were able to share one or two pieces of advice to your younger self as an aspiring head of product, chief product officer, what would maybe one or two things be that you’d kind of articulate?
For me, it’s understanding how do I get the most information out of every single failure. So, I’ve had a lot of failures that I’ve learned from, and it’s like, am I leaving any information on the table? Okay. Yes, we made the wrong decision because we didn’t talk to the right customers, but why did we not talk to the right customers? Or in terms of the questions we’re asking the customers we did talk to where, are we getting the most information out of them? So, it’s like, yes, there’s going to be failures, but try to get as much information as possible from those. That’d be one thing and the other is just, and this is something that I tell to most people that work on my team is – communication, you can’t overstate the value of communication. Being able to write your thoughts, making sure that people understand the reasoning behind why you’re making a certain decision, creating those artifacts that new people can come in and understand what’s going on and understand the reasoning, that helps you. It helps you scale, but also helps you build your brand. So, those are the two things that I’d say just top of mind, learning the most from the failures and continuing to invest in communication, both written and in presentation form. That helps you grow fast.
I’m struggling a bit with your go-to-market. Cockroach’s main advantage is scalability and safety, but that value appeals to larger enterprises. How do you scale down your value prop to acquire customers and grow them? For example, Mongo went after a novel paradigm and application developers for people who want SQL, they have Postgres MySQL. How does your technical differentiator align with your customer acquisition strategy?
So, there’s the scalability, there’s safety in terms of that transaction model, but for the smaller customers, resiliency is huge. So, if you’re a small customer, you’re building an application. Your customer has a new feature, all right, you need to make a schema change. That’s downtime depending on how you’ve built your system. All right, you want to upgrade to the latest version of the database, that’s downtime. You have a security update in your database. That’s also downtime. So this idea of resiliency is huge because customers, like going back to the end user, they expect the applications to be always on. Having a maintenance window is anti-pattern nowadays. So just to keep up with customer’s expectations, that resiliency value proposition is huge. That’s one of the things that we’re looking at, and that’s what we see in practice, because even with our global value proposition or our multi-region story around those low latency experiences, we’re still winning heads up versus Amazon Aurora in single data centers.
Some of that is due to future proofing. So, people see, okay, this is what the future will look like if we’re even moderately successful with an Amazon style database versus this is what it would look like with Cockroach. It’s a much natural story. It’s a database that can grow with you. But the other important thing is I don’t think we should underestimate scalability because there is more data being created by users just in the course of a day, that’s putting pressure on databases, because we’re not just talking about human generated data anymore. There’s more metadata that you want to capture maybe to train some machine learning model there’s more data and more state that is being created that is putting pressure on traditional relational databases. So, scalability relative to other relational databases is still a big value prop, but again, it depends on the workload.
What drove developers away from SQL to NoSQL, was that a grudge against SQL per se or was it more related to ACID?
The way I’m understanding this question is no one would leave SQL to go to NoSQL if they cared about ACID. So, from what I understand, let me just repeat that lineage. So, you start off with a relational database it can’t scale horizontally. To scale writes and reads, you have to scale up, which is expensive, and also that single machine doesn’t work well in cloud environments. That gets you to these NoSQL style databases. So, that was the trade-off. You traded scale for ACID, but that’s something you lost when you’re moving away from the relational database, and it turned out that losing ACID was a big deal. And so the question was, how do you get a distributed database that also has those guarantees and also has SQL. That’s where these new SQL databases like CockroachDB come into play. I want to make sure I answered that question because I don’t seem to follow it.
So we are at 3:30 on the dot. That was wonderful, Nate. Really appreciate it. What an incredible journey Cockroach has been on, and it was really interesting to hear your perspective as a person leading product and your journey and a bunch of different thoughts on value proposition and the history of databases and great thoughts on diversity and all those things. Really, really enjoyed this chat. So, thank you so much. Really appreciate it and hope to see you in person soon when the world comes back to normal, and again, as for everyone else, we will keep you posted on our next event. We don’t have a date yet, but we have some great speakers that have accepted to speak. So, we’ll let you guys know as soon as we can. And then, in the meantime, we’ll have those two conversations on video on YouTube and also on the FirstMark, on our website, FirstMarkCap.com. And we’ll let you guys know as well when we post those. So, thanks everyone. Really appreciate it. Jack, thank you.