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 Pearson and I'm the CMO at Snowflake. And 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 efraim, founder and CEO of Neo4J. Welcome and most importantly, how are you both today? Let's start with Emil. I have, from what I understand, you're in the south of Sweden, Malmo, or Copenhagen east as we also call it. How are things in Malmo today?

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

Great, 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 North's got some of its old energy back, minus the tourists.

Yeah, we really all need some 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. My 10 years at Google, when 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 sort of independent nodes that would colonize the available disk space and sort of 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. 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 you know, nobody ever forgets it and it is evocative. Right. This is a database that survives.

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

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

There's a little bit of that dark, dark side in the Neo for J name too.

No, no, it's all light and sunshine. Yeah. I guess initially, like we. When we. When we built Neo4j, the database 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.

And I was a big fan then and am today of the Matrix movies. And you have the main character, Neo, who's fighting against the Matrix, and the 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.

It was $2,000. And we grew up in the Java community and at the time there's this thing where you call things 4J, right. So there's a logging framework. You called it logging 4J log 4J. And one of my co founders, he said, let's just use Neo4j. And doesn't really make sense. What does Neo4 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. We have two French founders. They're big skiers, so they love snowflakes. Also, Snowflake is sort of built 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 one is, yes, everything is moving to the cloud. Number two, 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. Most companies at this time are in a situation where big Decisions need to be made for the future and that future is not five years from now. Most companies are already falling behind, 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 as 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 is giving you and I think of the cloud as being sort of a frictionless way to acquire what used to take months and you need to buy machines, put them into a co location facility. And many companies still operate on that basis. If they're in 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, across. 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.

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 across cloud that's something you see as an important requirement among your customers at this time or.

Fundamentally I mean the global 2000 so 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 five, 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 an integrated billing, you just get one bill and the services are hooked up with the identity, access, management, everything sort of works together. So that's a big win or has been a big win. When a company's making a billion plus in revenue and they have 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's 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. You know, it's 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, you know, they're both their ambitions and their technology stacks. And so people don't just want good enough like Amazon. Traffic's in 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 trail 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 like where we were 10 years ago and where we are now? What is really the skill set you need to have today to make the best decision for your company at this time?

You want me to answer that or Emil Sponsor Yeah, yeah, me. Well, you know 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 all the day one plus operations work would fall onto your development SRE teams. Now you can consume things increasingly as services. So 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.

Eme, what are you seeing here? And also I want to talk a little more about sort of, you know, how this, this more modern data stack, you know, looks like, you know as well, Emil, 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 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. You know, I can install MySQL or I can get a Linux distro with MySQL pre installed in like off you go type of a thing. Right? 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 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?

That's what we email now.

Yeah, so to me I think it's like for us what we see is that there's a very clear demarcation here basically when it comes to AI and ML, right? Where it. I feel like we got a little bit of that, you know, with, with big data, right? In the whatever ten plus 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, they needed, right. It went from that to big data all of a sudden, you know, business reviews wrote about it, McKinsey talked about it, right. And data is the new oil and all that kind of stuff, right? So that 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 kind 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 five 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 five years ago.

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

Yeah, I mean there's 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, that's very relevant to the business and the legal side of companies. I mean many companies out there are, you know, realizing it's a bit of a minefield to do business globally. And if you want to work not just in the U.S. but you want to expand to the EU, there's certain requirements and certainly user preferences around data sovereignty, domiciling residency. And that is 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? How are we really planning for the future? What new markets can we enter safely 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 sort of how this new modern data stack will look like. I think that maybe 10 years ago every company almost looked the same most for most companies. But today campus is going to 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, 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 going to 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. I think that's one piece of it. I've also seen disproportionate influence and investment in just more architectural pieces. If you think about the cloud, native movement if you will, with microservices on the development side, development time side and, and containers right on the runtime side. And you see serverless architectures and function as a service and all of that in many ways enables at least in theory it to be cheaper to plug and play services. And hey, I don't need to go wholesale. All in the previous kind of three tier architecture where I had one database behind it all, replacing that one was a massive, massive thing. These days, at least the theory is, and I sometimes see that realized with big Global 2000 customers, sometimes not. But at least the theory is that you can unplug, you can experiment with kind of with a smaller kind of damage radius if you will, if something goes wrong with a new type of data back end. 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 three stages. 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're 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. And now we're kind of entering a new stage, which is we would like to marry the great things about the relational SQL model with the NoSQL scalability, redundancy. And that's sort of the third phase of databases, which we're well into right now. So that's been from the perspective of someone that has been paying attention to databases almost exclusively. This has been a remarkably fast evolution industry.

Yeah. So both of you are engineers, right? As a background. Right. I know. Sponsor.

Guilty as charged.

Right. So you're both technologies 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, right. To make that shift, you know, into the cloud. But in your opinion, how important is it for data infrastructure to be fully cloud native at this time? You know, I'm personally, of course, a bit, you know, 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, I guess that wasn't the question, but even a 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 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, this was like it skipped like a bunch of layers in the stack, right. With EC2 was the first service out of, 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 a product strategy, just reviewed that for an internal thing in 2012, we had like, okay, we got to 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 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 you know 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 around cloud native. How important is it?

Yes, I go back and forth on that one in my head on one hand and I know we have a CMO on the call, so I'll tread carefully. I feel like it's a very marketing 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. So for example, like if you recall some of the early success of elasticsearch back when it was still elasticsearch, like one of the key things they did, which is a small thing, right is that if you start up elastic search as it was called at the time in aws, everything would just work so much better. Like it auto detected a bunch of things around your availability zones and stuff like that. You had to configure like 5% or so of what you had to do. If you run it on prem, there's an equivalent thing going on right now where like you just make sure that you simple things that you don't hardcore your IPs right. 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. I think we've seen a massive change just in the last year in terms of how financial services now is moving to the cloud, health care, 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 cockroaches, Right. I think it's one of the last things to move for a lot of the reasons that no 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, how they replicate, what kinds of backups they have and how quickly their time to recovery is. And those have evolved over decades. 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 you know, hopefully sort of a pincer movement. But on the one side you have to sort of, we think of this 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 know, you can't just say okay, everything's 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 pretty incredible. So obviously if you aren't planning for really all of those net new starts and 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 do that self hosted side and also build a cloud service. But fundamentally these cloud native technologies are enabling companies to get three 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 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 to Virginia to a data center and that's never going to give them that hundred millisecond latency rule that you always want to optimize for. So 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 and the a lot of the customers that you'd like to get just can't simply start everything new in the cloud.

Yeah, I really want to disagree. Unfortunately I agree with every 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 frickin 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 a laptop experience. Maybe not kind of it's server on prem1 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 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 the years that it's been out, 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 expanding to massive sizes in the cloud, I think that is requirement for developers in order for them to be on a plane, for example, and do their development and so forth.

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 has also been really, really strong and 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 from the support side, for example engineering, there's just a much broader swath of problems to tackle.

Both of you have a lot of experience, you know, 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 licenses.

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. Look, you know, 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, right? Which is to consume services. So again, it's like 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 in production. 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 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 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 a, an extremely powerful free tier so that developers can just not just kick the tires, but get hobby projects, hackathons. You know, this is like the top of funnel. The thing that we've 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.

I know, Emila, 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 is it's basically a self serve approach. Right. And I think what we've seen this is saster, right. So I'm going to 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, 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, 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 or developer businesses. So if you go in Entering through developers and you live in an on prem world. Right. That's what open source source is. Right. And then agreeing with Spencer. Right. 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. And so I think 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 products in the whole data infrastructure space, what would your advice 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 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 work 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 there 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 someone's 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, you know, 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 either complimentary feedback or even potentially, hey, I think this idea is not so great and maybe you should consider doing this 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 the right. No, I do agree that all that I'd add two things, one, 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 plus percent of the advice. But I love getting it and, and hearing it. But you're going to get a lot of advice on stuff that you should be doing. The one thing that I found over the whatever 10 plus 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 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 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 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.

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 can 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, 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 you around, you know, like having something that's maybe a little bit adversarial in that process, you know, can leave lasting echoes that can affect what needs to be a very strong relationship because it's likely someone's going to be on your board and it's going to 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 what incredible collaboration and relationship you have with your investors.

Yeah, I love all that 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. It's I'm a relationship guy. Like I'm a graph database guy. It's all about relationships in data. And I'm a relationship person as well, you know, 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 list thing is broken or whatever it may be, right. So that one is really important that personal Chemistry and then the second vector people call it in the visa world, like conviction investors or something like that. Basically you can find people who fall in love with your metrics 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. I want people who believe 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 prevent 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 first Vencer?

Yeah, I'll try to keep it brief. We struggled with that when we started. We were very much the open core model and 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. And 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, 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, you know, Elastics security features which is kind of their firewall to get people to pay and you know, it's, it's yeah, 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 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 three years. So for three 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 of the, you can fork it, you could resell Cockroach as a shrink wrap subscription software, you can run it as a database, as a service internally, you just can't do it externally. After those three years then Cockroach becomes Apache again. So the BSL only applies for three years and then you know, at that three year mark, three years after every release, kind of in a rolling fashion, it leads leaves a pure open source legacy of Apache. So that's three 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 pretty great reception for it. Wasn't a lot of naysayers. I think some of the open source purism has given way to a fundamentally more expansive idea of okay, if we want this open source to keep, keep getting developed 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 could 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 over to you Emil, to close this for us because this is obviously a question that all, all other.

Everyone, look, there are only two certainties in life. Like I usually say this, like 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 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. Right? 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. Right. So they can get the word out. So 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 or 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 break here to go to the next session. So thank you both and I think people can find you on both LinkedIn and Twitter if they have any additional questions for you. But thank you so much and have a good evening. Emil.

Thanks, Denise. Thanks, Spencer.