Paradigm Shifts and the Future of Data Infrastructure with Snowflake, Neo4j, and Cockroach Labs

All right. Hello, everyone, and welcome to this session where we're going to talk about the future of data infrastructure. We're also going to take some time talking about founders' advice, since our two panelists here today are extremely qualified to discuss both these topics. My name is Denise Pierson, and I'm the CMO at Snowflake. And I'm very excited to introduce our panelists for today. We have in the middle, we have Spencer Kimball, founder and CEO of Cockroach Labs. And to the right, we have Emil Afram, founder and CEO of Neo4j. Welcome, and most importantly, how are you both today? Let's start with Emil. From what I understand, you're in the south of Sweden, Malmö, or Copenhagen East, as you also call it. How are things in Malmö today?

They are fantastic. We are almost COVID-recovered, I dare to say. The latest 7-day tailing death count is now at zero, right? And the weather is beautiful for Sweden, so it's all good.

Great to hear that. And Spencer, you are in downtown New York, right? You are in NoHo, if I'm correct.

That's correct.

And I think we're also somewhat COVID-recovered here. I don't think it's quite as good as Sweden, but New York's got some of its old energy back, minus the tourists.

Yeah, we really all need some, you know, great news at this time. So I think we have a few things in common, but one of them is that we all have quite unusual company names. And I think the audience might be interested in hearing the background on these names. So can we start with you, Spencer?

Yeah, happy to do that. So Cockroach, before it was a company, was really just sort of a manifesto post. Post my 10 years at Google. I left in 2012. It was a little bit, I'd say disappointing, what the state of open source databases were compared to what Google had been developing for the past 10 years. And so the idea of an open source Spanner really loomed large. And I kind of have a dark sense of humor. And it did occur to me that the idea that would make sense would be a lot of independent nodes that would colonize the available disk space and greedily optimize, make sure everything was replicated and totally survivable. And I live in New York, so the idea of cockroaches was something that appealed to me. And now I spend time in all kinds of meetings with CIOs, Fortune 10 companies even, explaining the name. And it's a good icebreaker. But nobody ever forgets it, and it is evocative. This is a database that survives.

Yeah. And do you have mascots in the office too?

We call our employees roachers. So if you have a weird name like this, you really have to lean into it.

Yeah, but there's still a bit of that dark, dark side in the Neo4j name too.

No, no. It's all light and sunshine. Yeah, I guess. Initially, when we built Neo4j, the database, it was an internal project and we called it Project Neo because it was a new view of data and neo means new in Latin. Also, this was way back when dinosaurs ruled the earth in the early 2000s and I was a big fan then and am today of The Matrix movies. You have the main character Neo who's fighting against the matrix, and a matrix you can visualize as a table, right? And so that was that. But then when we wanted to actually spin it out and make a separate company out of it, we tried to get the neo.com domain name, but it was outrageously expensive. It was $2,000. And we grew up in the, in the Java community. And at the time there was this thing where you called things 4J, right? So there's a logging framework, you called it Logging4J, Log4J. And one of my co-founders, he said, let's just use Neo4j. And doesn't really make sense. What does Neo for Java even mean? But the domain name was $9, so we could afford it barely. One thing led to the other and I now run a company with a name that sounds like a password. Cool.

And well, the story behind Snowflake is that our founders are big skiers. There are two— we have two French founders. They're, yeah, big skiers, so they love snowflakes. Also, Snowflake is sort of built, you know, born in the cloud, and snowflakes, they come from the cloud too. And also, our founders felt that it was very easy for them to pronounce Snowflake too. They're French, so that was also another important criteria. So that's the main story behind the Snowflake name as well. So our first topic is really about how to prepare for the future when it comes to data infrastructure. And I think there are a couple of things that are clear to everyone attending this conference. Number 1 is, yes, everything is moving to the cloud. And number 2, data is becoming a strategic asset to every company. And we're also in the midst of a big generational shift when it comes to data infrastructure. So most companies at this time are in a situation where big decisions need to be made for the future. And that future is not 5 years from now, right? Most companies are already falling behind and need to move quickly. And on this conference here, we have a lot of founders that need to make decisions in regards to data infrastructure for their company. So the first topic is really about when everything is moving to the cloud now, what are the requirements and considerations that decision makers need to consider at this time? Do you want to start, Spencer?

Yeah, I'd be happy to. I think the present, as opposed to even the future, is the cloud. I think it sort of makes sense initially when people think of the cloud to do the same things that they were doing previously, sort of the lift-and-shift model. But when you really look at what the cloud is offering, there's an opportunity to exploit the resources it's giving you. And I think of the cloud as being sort of a frictionless way to acquire what used to take months. And you have to buy machines, put them into a colocation facility, and many companies still operate on that basis. They have their own private data centers and things. The cloud makes it so they can get these things programmatically in minutes, sometimes even seconds. And it's not just within a data center, it's across data centers in a region, and it's across regions on a continent, it's across continents. So you really want to think about, if you're going to use the cloud, it's not just about lift and shift. Hey, someone else is handling the data centers. It's really, we can build different things, not just faster, but better. We can build global services. We can push things to the edge. And I think that's really what I think about for the future. But fundamentally, this is about how do we change our business by fundamentally exploiting the benefits of the cloud. And that requires new infrastructure.

Yeah. Emil?

Yeah, I for sure agree with that. I think there's always a ton of stuff you can talk about here when you talk about kind of requirements and consideration for this. I think the only one thing, the high-order bit that I would add is there's a very interesting interplay right now going on between independent technology companies like our three companies and the cloud platforms, right? And obviously very self-serving for any one of the three of us here to claim that you should not go with a cloud platform-specific service, you should always go with the independent one. Of course, we're going to feel that way because we are those independent vendors. But I just, I would add that at least as an important consideration, right? Like, you can use a service that is native to whichever cloud platform you deploy to, and there can be many advantages to that where it's more plugged into other services and so on and so forth, right? You do end up becoming more coupled to that platform, right? And so just being aware of the trade-offs there would be like a high-order bit for me to add. Yeah.

So both of you, I mean, the cross-cloud, that's something you see as an important requirement among your customers at this time, or?

Fundamentally, I mean, the Global 2000s or the enterprise segment, they, I think, are almost allergic to what is known as vendor concentration risk. So it's one thing for a startup that, especially in the last 5, 10 years, to come to the public cloud, something like AWS. That was— the integrated ecosystem that AWS provides is actually an asset. You have— I hate to use this phrase, but one vendor throat to choke, right? And in integrated billing, you just get one bill and, you know, things are— services are hooked up with the identity access management. Everything sort of works together. So that's a big win, or it has been a big win. When a company is, you know, making a billion-plus in revenue and they have, you know, vendor management teams, and they really want to avoid having any vendor have significant leverage over them. I think most of them have had and continue to have a bad experience with Oracle, for example. Now cloud spend greatly outpaces what people used to spend on Oracle. And so that is a big concern. And so I think that even if a company starts on AWS, because that's where they have expertise, they are very eager to maintain flexibility and optionality. And I see this increasingly with startups as well. The multi-cloud vendors are in many cases much better, sort of best of breed. And startups are getting a lot more aggressive in terms of both their ambitions and their technology stacks. People don't just want good enough. Amazon traffic isn't good enough, in my opinion. Certainly, when it comes to databases. I can't speak for all the other infrastructure. It's a great product, but nevertheless, something like Snowflake or Cockroach or Neo4j, these are products that Amazon trails significantly in terms of their actual capabilities.

Also, this new generational shift puts different requirements on the skill sets as well, right, on the people managing your data infrastructure. What are you seeing as compared to where we were 10 years ago and where we are now? What is really the skill sets you need to have today to make the best decision for your company at this time?

You want me to answer that, or Emil? You want to jump in?

You can start, Spencer. Yeah.

Yeah. Me? Well, what's really interesting is that the skill sets, in some ways, have been allowed to narrow, because the method of consumption and deployment used to be that you download open source, and then you'd get VMs, and you'd be responsible for setting things up, and monitoring it, and all the A1+ operations, work would fall onto your development SRE teams. Now, you can consume things increasingly as services. So, yeah, to your point, I think it is about making the right selections of technology, fitting the pieces together, but it's more— I think most companies can get a lot further, a lot faster, because they're no longer responsible for as much of the deployment puzzle as they were previously.

What are you seeing here? And also, I want to talk a little more about sort of how this more modern data stack looks like as well. I mean, you are pretty cutting edge when it comes to data. So what do you think this modern stack will look like?

Well, first let me just piggyback off of one thing that Spencer said. One of the things that I always try to do on panels like this is I try to disagree because that makes it so much more interesting. And I agree with part of what you said there, Spencer. For sure, operational complexity has been reduced, right, in the sense that you don't have to bother running all these different things. But I do see that the surface is just so much more, like for anyone who wants to operate on data, we mentioned AWS before the, like they have, I don't know, 20, 30, you know, database services. And we can argue that they're at best good enough, right? You know, and this and that, right? But like, there's just this massive breadth of them. If you go back, I think you said 10 years, Denise, if you go back 10 years ago, it's like, hey, I'm a developer, I know SQL, I can install MySQL, or I can get a Linux distro with MySQL pre-installed, and off you go type of a thing. So I guess I see both of those vectors, where the operational complexity is reduced, or at least absorbed by the cloud platforms, but the product surface broadly is much bigger.

Also, what do you see in terms of— also talking to your customers in terms of more now how the business side and the technology side how they're collaborating within the company. And more, I think today, of course, the business side is more involved in that technology decision-making as well. Have you seen that shift as well among your customers?

Me or Spencer?

Emil, let's start with Emil now.

Yeah. So to me, I think it's like, for us, what we see is that there's a very clear demarcation basically when it comes to AI and ML, right? Where it, I feel like we got a little bit of that, you know, with big data, right? In the whatever, 10+ years ago, right? Well, all of a sudden data went from being something that just the geeks cared about, right? It was some underlying thing that made like IT work and, you know, the business side could get, you know, laptops and POS terminals and whatever they needed, right? It went from that to big data all of a sudden, Harvard Business Review wrote about it. McKinsey talked about it, right? And data is the new oil and all that kind of stuff, right? So that is, I feel like, was the first step. And then AI and machine learning comes along and like all of a sudden, all, every single line of business executive in the world is like, man, digital transformation, this digital transformation that we need to turn ourselves into machine learning company and those kinds of things. And all of a sudden we see them coming in, talking to IT and saying, hey, so in our universe, right? So I understand knowledge graphs are really important. It's one of the— graphs is one of the 5 pillars of data science as identified by Gartner, right? What are— dear IT org, what are you doing about graphs? And that we did not see even 5 years ago.

So is it much harder to be a technologist now, right, when you have that business side being constantly involved, you know, trying to tell you what to do at this time? Spencer?

Yeah, I mean, there's some other interesting things that we've seen with Cockroach. I mean, one of its capabilities is really that you get to do multi-region operation. And that's very relevant to the business and the legal side of companies. I mean, many companies out there are realizing it's a bit of a minefield to do business globally. And if you wanted to work not just in the US, but you want to expand to the EU, there's, you know, certain requirements and certainly user preferences around data sovereignty, domiciling, residency. And that is, you know, something that often the legal department is breathing down the neck of technology, and they have been for years. What are we doing with our users' data? You know, how are we really planning for the future? What new markets can we enter safely, you know, without too much liability to the business? Technology has become this sort of IT departments, how you deploy, what your data architecture looks like has become a much broader concern across the company.

Definitely. So, if we talk about how this new modern data stack will look like, I think that maybe 10 years ago, every company almost looked the same. For most companies, but today, I mean, companies are gonna build more best-of-breed stacks that makes most sense for them, right? I mean, how do you see this? Are there any guidance in terms of how to look at this? Emil?

Yeah, in terms of guidance, I mean, I think it comes back to, I think, the first point that I mentioned before, like, which is be aware of the consideration between what you mentioned, which is the best-of-breed technology approach versus the, hey, I'm just gonna do whatever is built into my, my cloud platform and nothing is right or wrong there. It's just different versions of trade-offs and risks that you're willing to take on. So I think that's kind of one piece of it. I've also seen like disproportionate influence and investment in just more architectural pieces, right? If you think about kind of the cloud native movement, if you will, with, microservices on the development side, right? Development time side and containers, right? On the runtime side. And you see serverless architectures and function as a service. And like all of that in many ways enables, at least in theory, it to be cheaper to plug and play services. And hey, I'm gonna, I don't need to go wholesale all in, in the previous kind of three-tier architecture where I had one database behind it all. Like, I had— replacing that one was a massive, massive thing, right? These days, at least the theory is, and I sometimes see that realized with, with big Global 2000 customers, sometimes not, but at least the theory is that you can unplug, you can experiment in a— with, with a, with a kind of— with a smaller kind of damage radius, if you will, if something goes wrong. With a new type of data backend. And I think I see a lot more thinking and investment in that as well.

Yeah. Spencer.

Yeah, I mean, over the last 10 years has been a pretty remarkable evolution of databases. I kind of think of it in 3 stages. And I guess maybe 10 years ago, we're kind of sort of starting into the second phase. But for most of the world's big companies, they are still in the first. So that first stage was SQL, which has been evolving for 40 years. And those architectures were monolithic. They sat in one place. You sort of had to scale them up. That kind of ran into a brick wall when the web happened. And so there was just a lot of innovation that was necessary. How do you actually build data architectures that can handle not enterprise scale, but global scale, web scale, people called it. And that really kicked off the NoSQL movement, which I think 10 years ago was the new hotness, right? Now, we're entering a new stage, which is we would like to marry the great things about the relational SQL model with the NoSQL scalability redundancy. That's the third phase of databases, which we're well into right now. That's been from the perspective of someone that has been paying attention to databases almost exclusively. It's been a remarkably fast evolution in the industry.

Yeah. So both of you are engineers, right, as a background? Right? I know Spencer—

Guilt discharged.

Guilt discharged, right? So you're both technologists at heart. So let's talk about technology considerations a little bit. And again, with all applications moving to the cloud, data infrastructure has really been last to make that shift into the cloud. But in your opinion, how important is it for data infrastructure to be fully cloud native at this time? I'm personally, of course, a bit biased here, also representing a company that was built for the cloud from the beginning. And of course, see the enormous differences in between that. So what is your— what's your opinion and recommendation here? In regards to that. Emil.

Yeah, so a couple of things, right? I agree with you, by the way, even like in— I guess that wasn't the question, but even the premise of the question, which I think is interesting and worth calling out, which is that this entire shift to, let's call it public cloud more specifically, right, is this super horizontal secular trend, obviously, in our industry, but the shift is happening at a different pace at different layers of the stack, right? And kind of weirdly, at least I feel like it's weird, like it started in kind of two ends. It started with applications, right? When was— when did we all start using like email in the cloud? It's like Hotmail or whatever. It's like gazillion years ago, right? And then VMs. So it's like it skipped like a bunch of layers in the stack, right? With EC2 was the first service out of Amazon, right? And so, so those happen to go early, and I, I'll be first to, to admit that I was very wrong about the shift in the data layer of the stack. Like, when we put together our product strategy, we just reviewed that for an internal thing in 2012, we had like, okay, we gotta move to the cloud, we have to have the database as a service available, and, and it took much, much longer, right? And, and I think it— the, the data layer of the stack was was held back by things like data gravity, but also the stuff that Spencer, you talked about around regulatory concerns and like if you're a big— if you have healthcare data or that kind of stuff, like you're not going to shift that into the cloud just like this, right? And that I think was an interesting and surprising thing to me. So I've now managed to talk about just the premise of your question and through that completely forgotten your question. What was your actual question?

The question was around, really, what around, you know, cloud native, how important is it?

Yeah, so I go back and forth on that one, like in my head, right? On one hand, and I know we have a CMO on the call, so I'll tread carefully here, I feel like it's a very marketing-y, you know, type of a term, and it's very ill-defined, which The engineer in me dislikes that part. I have to say though that I think it's really important for any type of new technologies, including databases, to be more sympathetic to underlying cloud primitives. For example, if you recall some of the early success of Elasticsearch, back when it was still Elasticsearch, one of the key things they did, which is a small thing, is that If you started up Elasticsearch, as it was called at the time, in AWS, everything would just work so much better. It auto-detected a bunch of things around your availability zones and stuff like that. You had to configure 5% or so of what you had to do if you ran it on-prem. There's an equivalent thing going on right now where you just make sure that you— simple things like you don't hardcode your IPs because you want them to be injected by by your container management system and things like that. And that just makes it much lower friction to deploy your database in a more cloud-native type of an architecture. And I think that kind of stuff is really important. And then on a more fundamental architectural level, things like being able to decouple storage and compute, I think, is increasingly important in a cloudy world.

Things are moving incredibly fast here, right? I think we've seen a massive change just in the last in terms of how financial services now is moving to the cloud, healthcare, all of that, right? So I think it's accelerated just in the past year. Spencer, what are you seeing?

Absolutely. There's, you know, it's a complex thing for the system of record, which is what Cockroach is, right? I think it's one of the last things to move for a lot of the reasons that Emil mentioned. You know, there's just InfoSec requirements, I think, you know, If you think about all of these regulated industries, especially financial services, they have all kinds of compliance that they have to meet with, and that involves a lot of different controls, both on how their employees interact with the data and the systems that they put up, you know, how they replicate, what kinds of backups they have, and how quickly their sort of time to recovery is. And those have evolved over decades, right? So to just move to cloud, especially service, it's very difficult for these larger companies. And so we kind of think of our mission on two fronts, and hopefully it's sort of a pincer movement. But on the one side, you have to sort of— what we think of as building a bridge for these big enterprises. You have to meet them where they are. And often there's a very hybrid reality. And when they get into the cloud, they really want multi-cloud. But you can't just say, OK, everything is going to be as a service right now. Or you're never going to get those big customers because you're not meeting them where they are. But on the other hand, I mean, Gartner thinks that by 2022— this seems insane to me, honestly— but 75% of databases will be deployed or migrated to cloud platforms. That's, that's pretty incredible. So obviously, if you aren't planning for, you know, really all of those net new starts and, you know, I guess increasingly migrations as well, then you're going to miss the boat. But you have to do both of those at once, which really complicates the task. Whereas Snowflake, you guys had the, I think, immense good fortune to just start in the cloud, to be born just strictly as a service. I think that complicates our world, that we have to sort of do that self-hosted side and also build a cloud service. But fundamentally, these cloud-native technologies are enabling companies to get 3 huge benefits. And I kind of mentioned that within a data center, it's about scaling horizontally. Across data centers, especially availability zones that are fairly close together, you can replicate so that you just have complete business continuity. And then I think the real exciting thing for the 2020s is building for the edge. The idea that even startups right out of the gate just getting product-market fit, they can end up with customers in Brazil or in Turkey or in Japan, right? And you want those. You don't know where you're going to get that critical mass. And you'd like to be able to operate in a way that keeps the data in their legal jurisdiction. Sometimes it's an actual hard requirement, certainly is a user preference. And you want to optimize for latency fundamentally. You don't want your Australian users that love your product to have to jump across across to Virginia to a data center, and that's never going to give them that 100-millisecond latency rule that you always want to optimize for. It's very clear why companies want to embrace cloud-native, and it's an interesting set of challenges when you are the system of record. A lot of the customers that you'd like to get just can't simply start everything new in the cloud.

Yeah, I, I really want to, to disagree. Unfortunately, I agree with everything single thing you just said there. I would add to that that I 100% agree that one of the things that Spencer, that you and I have to do right now is running a startup, kind of high growth, at the same time go through the organizational transformation of being able to do both on-prem and cloud at the same time, which is freaking hard, right? And Denise, you didn't have to do that because you started in the cloud, which is, I think, an amazing advantage from that perspective. I think the flip side, and then this is me being an entrepreneur and seeing the glass half full, right? The flip side is that I do think that developers today, probably also data scientists, but at least developers today, they do want a local experience. So if I would have started all over again in 2020 from scratch, I for sure would have made it cloud-first, but I also would have built like a— let's call it like a desktop or laptop experience. Maybe not kind of a server on-prem one, but at least that I would have done. Is that what you would have done as well, Spencer?

Yeah, actually, that's a really great point because Google Spanner, which, uh, you know, works very nicely within Google, and then they made a cloud product, that's something that you simply can't run on your laptop. And in, in the years that it's been out, it, I think it took them several, they kind of have a little emulator that you can run locally. But yeah, having something that works on a laptop as well as, uh, you know, expanding to massive sizes in the cloud, I think that is a requirement for developers in order for them to be on a plane, for example, and do their development and so forth. So yeah.

Just that local kind of rapid iterative experience. And then I think the other thing that— so that's kind of the developer side. And then on the CIO side, at least for us, interesting to hear how, what you see, but for us being able to talk to a CIO and say that, Hey, we run everywhere, right? Like we run in your data centers if you want to, hybrid cloud environments, in whichever public cloud, on your developers' laptops. That pervasiveness argument is also— has also been really, really strong. And it comes back to that whole multi-cloud, all eggs in one basket type of a thing.

Yeah, we've definitely seen the same thing, but as we've already pointed out, it's a lot, you know, from the support side, for example. From engineering, there's just a much broader swath of problems to tackle.

Both of you have a lot of experience with open source as well. So where do you see open source play in the future? Can we get anything contradicting here from you, Emil? Let's start with Spencer and see what Emil have to say about it.

It's good if I go first, because then Emil can disagree with me.

I can find something to disagree with. Let's argue on licenses.

Yeah, I actually do think that open source remains incredibly important. And that's really from my perspective as a developer. I wouldn't use a database that wasn't open source in 2020. It just feels wrong to me. That said, open source took over the world, not necessarily because of the ideals of having the source code available. I mean, that's sort of more the open source purist perspective. It took over the world because it was a far more efficient consumption model. Previous to open source, it was absurd what you had to do. There was no community. You get printed manuals. You'd spend months with vendor management trying to negotiate some sort of sales contract. It was a very slow process. Open source changed everything. So developers can simply go online, download the things, run them, and so forth. Search on Google, find a Stack Overflow answer that gives them the exact recipe that they're looking for to get what they want to get done. But now open source, that consumption model, so much better than what came before. There's a better one now, which is to consume services. Again, we mentioned this before, but now a developer gets to simply work on the API something they want to work with, as opposed to having to actually understand how to run it. And, you know, much less if you actually had to put it in production. There's just a— there's a lot of details in terms of how to successfully and responsibly run something in production. So now I'd say that we've got a new consumption model for the 2010s, 2020s, which is as a service. So how does that— how does— what's the interplay with that and open source? And that's a very interesting question. I think that the best services are ones that are based on open source, based pretty strictly on open source, in fact. I don't like when people put a lot of special sauce on top of the open source that makes the service very different from what it would look like if you ran it yourself on your laptop. I think it's best if those two things have a very high degree of symmetry. And, you know, I do think that there is also this idea of open source, which It's the free beer side of open source. Developers do not like paying for things. Developers do not like putting credit cards down. So what you really want to do is have a service that's based on open source and also have an extremely powerful free tier so that developers can not just kick the tires, but get hobby projects, hackathons. This is like the top of funnel. Come face-to-face with more and more frequently is that developers make decisions. And every company in the world, from the smallest to the largest, it's just developers all the way down. So if you can capture mindshare with developers, it can make a very efficient sales engine. And that's what we're all looking for in terms of making our companies a success.

And I know, Ian Millat, you're not going to have much contradicting views on this one.

I was going to say, tragically, I agree with— with all of that. But I guess the only thing, agreeing 100% with what Spencer said, I would add, at least the way that I think about open source is kind of the high order bit for, not even the high order bit, but the kind of the higher order view for me on open source is that what open source, the business objective that it serves for the vendor, right? Is it's basically a self-serve approach, right? And I think what we've seen, this is SaaStr, right? So I'm gonna assume there's a bunch of startup founders and executives in the audience, right? And we've now have objective data on the fact that product-led growth companies on balance grow faster than ones that are sales-led, which makes intuitive sense, I think, to at least, to me, right? Because it's just a better customer journey, right? If you can talk to a human being, but you're not forced to do it, right? You know, that's a better customer experience. So it makes sense that that one wins out over the long term. And open source, the way that I now look at open source is that it really is self-serve first or product-led growth specifically for on-prem with B2D businesses. So business to developer. Businesses. So if you go in and dream through developers and you live in an on-prem world, right, that's what open source is, right? And then agreeing with Spencer, right, then like an even more powerful thing then is if you can— if you already have that product surface, you can self-onboard onto it, right? If you can then remove the operational pieces completely, that's an even more powerful combination. Um, and so, so I think the— there is that tight interplay between open source and cloud when it comes to developer-facing products like databases.

So we're going to jump into the next topic here before we take some questions from the audience, because we have questions coming in at this time. And it's always exciting to talk to two founders like the two of you, obviously. And I know you have a lot of advice to share with other entrepreneurs just kind of entering this whole data space. So what would your main advice be if there are any other founders here that now have new, new products in the whole data infrastructure space? What, what would your advice, you know, be for them at this time? Spencer?

Yeah, I've got a ton of advice. I'll try to keep it brief. And certainly I, I would I'm a big proponent of having co-founders, at least one. And you shouldn't just choose someone that you've known for a month or two. Ideally, it's someone that you've worked with in a past incarnation pretty extensively. You've been in the trenches. I just think being a sole founder and presumably the CEO is a pretty lonely job, and it's wonderful to have long-term colleagues they're with you. Also, I think a mistake that a lot of people make, and it's certainly not limited to the data infrastructure space, I think this applies to essentially everything. People get very cagey about the value of an idea. They think that if, boy, they don't get people to sign NDAs and they're worried about VCs talking, And so they create this bubble around themselves, and there's not a lot of good, maybe very contradictory advice coming in. And I think that's a good way to spend a lot of time and effort only to fail slowly instead of to fail quickly or to evolve quickly. And so my advice to everyone is do not believe that your idea is somehow worth anything. Ideas are cheap. They are very cheap. Whatever idea you have, someone else has had it. You want to get out and tell everyone about your idea. That should involve Hacker News, right? Like, if you can get on the front page of Hacker News, believe me, you will get so much more interesting support. You'll get people that want to join your company. You'll get VCs interested. So you want to, you want to blog and you want to write, you want to tweet, you want to, you really want to get the word out there. I mean, I love talking to VCs personally. I'll talk to any one of them that, that's interested, because they really are mostly pretty smart, and some are like incredibly smart. And having them disagree with one of your ideas or give you, you know, either complementary feedback or, you know, even potentially, you know, hey, I think this idea is not so great, and maybe you should consider doing this, is, is very valuable. Like, if you can't address the criticisms that come your way from smart people, you're going to build the wrong product fundamentally. So I think, yeah, just be very open. Sunshine on your idea makes it stronger.

So you need to be a strong communicator yourself, obviously, but also listen a lot to advice. Well, I don't think you're gonna contradict this one either, right?

I'm trying really hard, but that was so That was so right. No, I do agree with all that. I'd add two things, one big and one small. The big one is that I also actually like talking to VCs and I love getting advice, especially when it's advice from people that I— where I don't have to take the advice because I ignore 95+% of the advice, but I love getting it. And hearing it. But you're gonna get a lot of advice on stuff that you should be doing. The one thing that I've found over the, whatever, 10+ years now, is that it is impossible to over-index on customer empathy. Like the more time you can spend with customers, with the users, like, and just, you should be able, in the early days, you should be able to just paint a perfect picture of your ideal user's day. What do they do when they wake up? What site— Spencer mentioned Hacker News— where do they go to get their information? Just understanding absolutely everything about them, right? So I think that would be kind of the big one. I think the small one, I guess you asked specifically about kind of entrepreneurship in the data space, it comes back to what I said before around self-serve first or product-led growth, just investing in getting the product to such a state where you can self-onboard, which is a product thing, but it's also the entire company, right? Like you have to have documentation, you have like, there's all kinds of aspects that go into it. But that is, that is an investment that will compound over the years in ways that almost very few other things will do, maybe outside of like people, internal things like culture is also one another thing that compounds. But in terms of strategy, just investing in that self-service piece in the data space, I think, is really important.

I mean, you both made a couple of large funding rounds yourself. Any advice you have to anyone here who's looking for VC funding?

I'm happy to answer that. I think one thing to do is just to be scrupulously honest and straightforward. I usually don't play cards close to my chest. I really over-communicate, and I think that's just a mark of respect, and VCs appreciate it. Certainly, if you're trying to make a VC round come together, it really helps to have an anchor term sheet. So if you can get somebody to go in, even if it's not necessarily who you most would like as your lead, that really precipitates the round. But again, it's not something that I would ever recommend you get cagey about. Like, you don't really have the term sheet or the commitment, you can't say you do. And I think that just being very above board in everything you do and very straightforward, it just pays off. People— it's not actually very common, apparently, but if you do do that, you will build the right kind of relationship with the VCs that do lead your round. Like having something that's maybe a little bit adversarial in that process can leave lasting echoes that can affect what needs to be a very strong relationship, because likely someone's going to be on your board, and it's it's gonna be next 10 years. And you really want that person to be someone that you trust and that they trust you.

And Emil, I sit on your board, so I see how, what incredible collaboration and relationship you have with your investors, right?

Yeah, I love all that Spencer said, and I approach it, just try hard to approach it in the same way. I'd say there are two vectors that are the most important ones for me in the past for choosing investors. One has been, and I think very related to what you said, Spencer, which is that personal chemistry, right? Like it's— I'm a relationship guy. Like I'm a graph database guy. It's all about relationships and data. And I'm a relationship person as well, in life, right? And so that part is really important because it really allows that kind of vulnerability-based trust where I can come to them. It's like, all right, I fucked up over here, or like this thing is broken or whatever it may be, right? So that one is really important, right? That personal chemistry. And then the second vector, people call it in the VC world like conviction investors or something like that, right? Basically, you can find people who fall in love with your metrics, right? Or you can find people who fall in love with you and the idea and what you want to achieve. And I've always chosen the latter, right? Like I want people who believe, right? And that's a personal preference. I could have gotten fancier valuations or whatever without that probably, but those are the two axes at least that I've looked at.

Yeah, I actually think that— I just want to reiterate that last point. I think that's incredibly wise. The last thing you want, in my opinion, is an investor that you have to convince that your idea is a good one. Because that person, anyone that you have to convince, isn't approaching the idea as a good idea from first principles. So they're not going to give you anything. Beyond agreeing with you if you convince them. If you get somebody that says, I've been looking for something like this, I've got my own theories, maybe it's not exactly yours, but almost certainly it's going to be complementary. And that's someone that can really give you sustained advice because they've reached similar conclusions about the space.

Yeah. We're going to take a question from the audience here. And this is a question that you are getting all the time, and the question is, what prevents Amazon to take your open source and make a new multi-cloud Aurora DB? A lot of startups and investors are mindful of this, and I'm sure you get that question all the time in regards to Amazon.

Never thought about that. Do you want to go, go first, Vencer?

Yeah, I'll try to keep it brief. We've struggled with that. When we started, we were very much the open core model. It looked like it was a great model, right? Elastic had done a good job with it. I think they were the ones we were paying the most attention to. It felt like, okay, you can have a very strong open source core, and you can build a constellation of enterprise features around that. As long as you draw the line appropriately in terms of what's—

Yep, you're still here.

Something just went away from me.

Oh, there we go.

As long as you draw the line appropriately, that can be, I think, a very strong model. Amazon kind of found the loophole in there, and they sort of punctured the model. And the way they did that is they open-sourced Elastic Security features, which is kind of their firewall to get people to pay. And Amazon open-sourced it. It's almost like that's altruistic. But in fact, what they did is they took a lot of the wind out of the sails of the company that was actually investing in the open source project. So it was, I think, very predatory. But you know what, it's, you know, all's fair. So what we did is, in response to that, we decided to relicense our core. And we chose what's called the Business Source License, the BSL, which is something that MariaDB came up with. And it has sort of two blanks that you fill in. One is the term, and then and then you also set a list of exclusions that apply over the course of the term. So our term is 3 years. So for 3 years, we have on the core one exclusion, which is that you can't run Cockroach as a commercial externally available database as a service. So it's in some ways the anti-Amazon RDS exclusion. You know, otherwise you can do everything with it, all the source codes available, available. You can fork it. You could resell Cockroach as shrink-wrap subscription software. You can run it as a database as a service internally. You just can't do it externally. After those 3 years, then Cockroach becomes Apache again. So the BSL only applies for 3 years. And then, you know, at that 3-year mark, 3 years after every release, kind of in a rolling fashion, it leaves, leaves a pure open source legacy. Of Apache. So that's, you know, 3 years innovation window. It's kind of like a little bit of patent protection. Our customers don't have a problem with it. In fact, I think they're quite supportive of it. Hacker News, there was, you know, pretty great reception for it. There wasn't a lot of naysayers. I think some of the open source purism, you know, has given way to a fundamentally more expansive idea of, okay, if we want this open source to keep getting developed and the way that a company like Cockroach develops it, then they have to have a sustainable business model. And the one that we had originally settled on, where we have just a pure Apache core from the beginning of each release, just doesn't work with some of the evolution of Amazon's approach to open source.

I'll turn it over to you, Emil, to close close this for us? Because this is obviously a question that all other founders—

Hey everyone, look, there are only two certainties in life. I usually say this, one is we're all going to die, and the second one is we're all going to compete with Amazon. And I'm not even sure about the first one. So look, I guess that— so we've done a very similar, not technically the same license, but very similar approach. We have a different license where Amazon can't take our product and run it themselves. And I think for us, I guess the perspective I would take is that like when Amazon starts to compete with you, I think there's a big fork in the road, right? So Amazon enters your product category, are they able to enter your product category with your product or do they have to enter with another product, right? And where, like Elastic— many of these other firms are not Cockroach, not Neo4j, not Snowflake, is that they've entered your product category with your own product, and that's a world of pain. It is just horrible. But if you enter your product category with a different product, as long as that product is nowhere near as good as yours, which typically it isn't because your entire company is focused on that one product, and because of how early in the days you over-indexed on customer empathy, you built a much greater product. Then at that point, it's actually net positive. When they entered the graph database space, it was one of the key accelerators of the entire space because Amazon is temporarily a bigger company than Neo4j, so they can get the word out. We actually saw that as a very positive sign when Amazon entered into our space with a competing product, but that's because we were able to from a legal perspective, from an IP perspective, stop them from doing that with our own product while remaining open source.

Exactly. Yeah. So I want to thank both of you for a very interesting discussion. I want to thank the audience as well. I think we need to give everyone a little break here to go to the next session. So thank you both. And, um, I think people can find you on, on both LinkedIn and Twitter if they have any additional, you know, questions for you. But thank you so much and have a good evening.

Emil, thanks, Denise.

Thanks, Spencer.