The below is a full (unedited), machine-generated transcript of a Youtube session / podcasting episode I recorded with Spencer Kimball, the co-founder and CEO of CockRoach in Q1 2020. You can view the video/listen to the podcast on Youtube, Apple Podcast, Stitcher or wherever you get your podcasts.
Erasmus Elsner 0:08
All right. Welcome to another episode of Sandhill road. And I’m super excited to announce my guest today. Spencer Kimball, who’s the co-founder of CockroachLabs. Spencer, ready, to take us to the top.
Spencer Kimball 0:20
Yes, absolutely. Thanks for having me.
Erasmus Elsner 0:22
And I’m so honored to have you on just one week after being on Jason Calacanis’ show “This Week in Startups”. And I learned from his show that you’re based in Noho in New York, but where does this podcast find you today?
Spencer Kimball 0:37
Today I’m in the East Hampton, which is on Long Island, kind of really, just the end of Long Island. Weather is great. It’s nice to be out of the city, even though cities actually got some pretty good energy in August with all the outdoor dining and no tourists mucking up the works.
Erasmus Elsner 0:56
So let’s talk a little bit about CockroachLabs. The company is announced in the midst of the corona crisis in 86 point 6 million series D funding led by our meter capital and merrymakers bond fund on the spectrum of startups who have COVID headwinds, and those who have COVID tailwinds from the outside, it looks like coverage Labs is really placed within those pocket of companies who’ve really benefited from the large move online providing part of the backend infrastructure of the internet, but maybe give us a little bit of a highlight of what cockroach lab does the two minute pitch and how it has fared through the crisis so far.
Spencer Kimball 1:33
Yeah, absolutely. Cockroach Labs were building primarily a relational database. So in the tradition, long tradition spent 50 years now a company is like Oracle, IBM with DB to Microsoft SQL Server. The difference is that cockroach has reimagined the relational database to exploit the cloud. And the cloud is what’s fundamentally different. And we’re not really breaking, we break some new ground. But we’re also following in the footsteps of Google did a lot of this r&d over the decade that I was there in 2002, to 2012. And really, what we’re, what we’re doing is you’re saying, Okay, well, the cloud is fundamentally about making resources frictionless. And those resources can come within a data center, which is sort of the traditional way to think about building software, everything runs in one location. So you can get lots of machines, you can get them in minutes. Keep in mind that back in the day, this used to take months for a company with a new team spinning up a new service, to allocate machines, get them put into some colocation facility, and get these things in minutes. And you can get them programmatically. But you can also get resources, not just in a data center, but across data centers, for example, in availability zones in AWS on the east coast. And this lets you do really fancy things with replication. So you can survive an entire data center going away, which is a huge advance. I mean, when I say survive, I mean, you have maybe a several seconds of latency, but no chance of data loss and just complete business continuity. And then you can even extend the idea of what the cloud gives you further and say that the cloud can give you frictionless resource acquisition, even across continents. So you know, even a startup these days can have customers in the EU in the US and Australia. How do you give all of them a first class user experience in the cloud, at least is telling you hey, we can give you on AWS or GCP or Azure cloud or whatever, we can give you resources across continents, we can cover the entire world. And you can get those all programmatically and within minutes. It’s kind of an amazing thing. But what about the old databases, because Oracle can’t use that stuff. That’s not it wasn’t architected for this era is architected for decades past. So we there is a brave new world, but you really do need to think of infrastructure differently, to really build that next generation of applications and services. For example, the way that Netflix or Facebook or Google builds things, right? If you’re using Netflix, and you’re an Australian us customer in Sydney, you don’t have a crappy experience where you’re jumping over to Virginia, every time you’re trying to access the backend of Netflix, you’re actually accessing the servers and the data and the applications. And it’s all stored close to that customer and in Australia. That’s what everyone wants to build in the next decade. But so far, that’s been sort of the province only the super high tech growth companies. And now that’s sort of becoming a democratized capability. And, you know, cockroach is building the database, which is a critical part of any application stack that can actually accomplish that sort of data architecture goal.
Erasmus Elsner 4:29
Super exciting. And let’s talk about the early days of cockroach and getting the band together. If I think about the perfect sounding team, it’s a team that has deep domain expertise in a field was worked together for years, maybe even started a company together before and your team had the fortunate position to have all of these ingredients in one place. You did your your undergrad in computer science at UC Berkeley, Go Bears while at Berkeley, you built the the graphics editing tool together with Your roommate, Peter matters where you met there. And who is now also a co founder of Cockroach Labs. And then later on both of you co founded few finder, which was later sold to square. from an outside perspective, this looks really like the perfect band, but maybe you can add some color to how this this team came together. Yeah, absolutely.
Spencer Kimball 5:21
You did mention two startups that they’ve done, there was actually a third, which I did right out of college. Actually, I had two jobs before, but they were both pretty brief stints. This is during the.com. Boom, I learned each step of the way, sort of the the do’s and the don’ts. And I do fundamentally believe that any entrepreneur with fire and a passion for something can be successful right out of school. But there’s advantages to doing it when you’ve had a lot of industry experience, and you’ve seen the problems up close and personal. You did mention, it’s great to have worked with people before, I think that’s actually what I would say, is the most critical point. And one I give as advice to anyone that asked me, they do want my advice, which is being in the trenches with, you know, somebody else, and really, you know, seeing the highs and the lows, and particularly the lows, and still having a lot of respect for that person in terms of their work ethic, and their temperament, when things aren’t going so well. And even when they’re going well, you know, people can turn pretty horrible sometimes when there’s a lot of success at hand, you know, that actually forms the basis for a level of trust that is essential, you know, throughout the difficult, you know, twists and turns of the startup experience. And in those first two startups I did, you know, before cockroach, you find or you mentioned, there’s another one called weego systems back in 1999. All of those, those two original ones were done. Partly with people that I knew, in each case, one other person, and then partly with people I didn’t know well. And in both of those cases, the people I didn’t know Well, those become came major points of contention were when things weren’t going so well, those nascent relationships didn’t really have the deep and abiding respect and trust that I think is necessary. So with that, if you find a friend with cockroach, we’ve had, you know, Peter, and I’ve been working for 27 years together, and Pete Ben and I have been working for 18 years together. So we have seen it all, we’ve worked on so many different projects, probably at Berkeley, as you mentioned, and at Google and viewfinder, and so forth. So that was that was hugely important. And a big piece of advice that I think holds true, no matter whether you’re doing a start up out of college or, you know, after 20 years in industry. And I think the other big thing I mentioned passion, I think there are cases where people get sucked into startups, especially as a technical co founder would be goal of the startup. You know, the raison d’etre is not something that the founder isn’t necessarily passionate about. Like, sometimes they’re trying to put on the hat of, you know, the customer that they’ve never been, right, maybe you’re doing a healthcare startup, and you kind of understand why people would want it. But you haven’t had that much experience yourself, as you know, whoever, whoever it is that you’re solving the problem for. I think that puts you in a dramatically less viable position. It’s so much better when the passion that you have or something is born of your own frustrations. And you really understand the customer journey and where it’s going wrong. And the problem that you’re solving. Those are the two pieces of advice, I think are critically important. And with Cockroach Labs, boy we had, we had those in spades, right, we had, we had an incredibly incredible history of the founding team. And also, in my entire career, after graduating from Berkeley has been, fundamentally one we’re fighting against the shortcomings of databases. So you know, defining work concertedly on just that problem, and really solve it, and like, what would I most like to see from a database? The next time I’m on the side of building an application, and all of those things that I’ve learned over 20 years, I’ve kind of come to a head in cockroach. So that’s super exciting. And it gives you the necessary drive to keep on plugging away even when things are, you know, getting getting difficult.
Erasmus Elsner 9:23
So you sold Viewfinder to Square. And then after a year or so you went to your co-founders and said, Let’s do it again. How did these conversations go? Are they like, oh, man, let’s just rest invest for a bit. How did these conversations go?
Spencer Kimball 9:38
Yeah, it was a bit of that. Certainly, it wasn’t too hard to convince them. I think all of us definitely understood why cockroach should happen. When we left Google in 2012, Google felt about 10 years ahead of the larger ecosystem. Just you know, I think that that lead has shrunk dramatically, but you In 2012, it was really apparent that what Google built with big table and then mega store and then Spanner, this was an inevitable set of capabilities, which, when we, when we did you find it, we realized, Wow, so many of the problems that we had to solve would be trivially solved if we had a system like Spanner. But there was only inside Google at that point, when we got hired by square, we realized, wow, square has problems that also could be trivially solved by Spanner, which they are contorting themselves into knots really to work around, you know, their use of things like h bass, and MySQL is just not the right solutions. When you’re at that point in time. You know, it’s 2014. So the conversation with pig Ben, I think Ben was more on board than Pete Pete was, I think, a little less interested in just doing it all again, you don’t get paid much when you’re doing a startup, right, we had a very good situation at square square is a great company. You know, it was comfortable there. And, you know, there was definitely a lot of equity still on the table. So leaving wasn’t the first thing that we really wanted to do. But it’s one of those moments where you kind of feel like wow, you know, if 10 years at Google was worth anything, it was this ability to look into a crystal ball 10 years into the future, at Google being 10 years ahead of the ecosystem, to the extent you think the ecosystem is going to follow in their footprint, footsteps, which we did believe, you know, it seemed like a waste to say, Okay, well, we understand what the future is, but we’re not going to go and invent it. We’re just going to keep it on the side.
Erasmus Elsner 11:35
But I hear you, if you have this special insight into a vertical or technology, then you just have to take the leap read. And I saw that you didn’t raise a seed, think you could probably bootstrap to the first version of the product. What did the first version of cockroach DB look like?
Spencer Kimball 11:52
Yeah. And then it wasn’t very, it wasn’t very functional. Yeah, the first version, it was something that I was working on while I was at square. And then Ben joined me. And then some other folks joined as well, some, some that were at square, some that were just random people are interested in the GitHub project. So that was for about a year. So that was something that was viable, there was a design doc that got a lot of interest, which was very helpful. And that was enough for us not to raise a seed, but to go directly to a series A which benchmark LED, and were joined by Sequoia and Google Ventures, and several others. But, you know, that early project wasn’t yet sequel, as an example. And that’s something that we decided as soon as we actually raise money, okay, SQL is really where the market is, that’s what we need to do, not just a no SQL system. And, you know, but it was, you know, you had to classify that early version of cockroach, we raise money as being alpha, definitely not suitable for production under any circumstances. But enough of a realization of the idea that the GitHub project already had 3000 or 3500 stars, which, you know, the VCs taking a look at that, that that represents something real. You know, interestingly, for an open source project like cockroach, there was still a long way to go in terms of the investment necessary to get to a general availability, production ready release. Typically, with open source projects, you have a situation where it’s stewarded and sort of incubated and then fully brought to production within a company like Yahoo, or LinkedIn or Google. And then those things get released, sometimes in the Apache Foundation, but it’s previous like Cassandra, right, it, you know, there’s work to be done still. But it’s a it’s a viable piece of software already. With cockroach, you know, we’re still alpha. And a lot of the realization is that when we raise this money, it would be about, you know, creating the necessary r&d to really bring it to market. And that was going to be a multi year journey, even before we could start selling the product. So it really was a leap of faith for our investors, and slightly different lead in to building an actual commercialization strategy around an open source product, but we had to do the the investment first and the R&D.
Erasmus Elsner 14:17
Let me double click a little bit on this open source commercialization. I think in one of your blog posts, you recently covered the three dominant business models in commercial open source. The first one being, obviously the services model, which was pioneered by Red Hat, which has fallen a little bit out of favor or diminished a little bit in importance. Then there’s obviously the dominant one, the open core model, where you have specific premium features that you offer in a paid version. And then there’s the hosted model. In this blog post of yours. You mentioned that you see eventually Cockroach Labs adopting a combination of the hosted model and the open core model. Talk to us a little bit about how you landed on the open-core model, and whether you ideated or iterated on some of these other models?
Spencer Kimball 15:05
Yeah, you know, a lot of these things are just a function of the funding environment, and the received wisdom that you have, as a startup founder, as you go around, you start talking to VCs, VCs are really good pattern matches, and especially if you’re talking to the cream of the crop and the VC world, you know, you take them pretty seriously. And they do share a lot of wisdom with you, which is why I think it’s important as, as a founder to, to not worry about things like NDA, I mean, I guess he really, he really want to, you really want to sort of pull out the stops and shine a lot as much sunlight as you can on your idea. And you can pick up a lot of interesting opinions along the way, which helped to, you know, form your own opinion about things. But the open core model in 2015, was definitely still Ascendant. And you had companies that were doing a good job with a from confluent, to elastic, to MongoDB. And the, you know, the didn’t feel like the hosted service was, or the managed service was, it had as much traction. And so, you know, you kind of just fit in where you think that your commercialization is something that’s going to attract investors fundamentally. And the received wisdom in 2015, was open core was was approved, proven model, and it was going to work. And it also felt he was to look at what it is you’re selling, we’re infrastructure software, but we’re a special category of it. We’re a relational database, which is really the system of record the source of truth. And many companies, for reasons of sometimes, you know, regulatory compliance, sometimes just a very evolved, maybe decades evolved Infosec internal requirements process around, you know, how their employees devices are controlled, what sort of regulatory compliance regimes that they solved all the problems, you know, posed by the compliance, you know, using various pieces of software, it’s a very tangled web and interconnected, just moving into a hosted service, the way Amazon was providing RDS at that time, is a huge lift for an enterprise company, this, let’s say, done 10 years of compliance and regulatory work to get whatever their their mission critical software, you know, to make that worked for the compliance regimes, within their own data centers, and so forth, trying to lift and shift that into Amazon’s RDS in 2015, absolutely not going to happen. So our realization, as we want to sell to these global 2000 Enterprise segment of the market, if there’s, they’re gonna have to run it themselves. So the hosted service felt early and even in 2020, it’s still a little early once you get outside of this sort of high growth tech companies. And that’s just the reality. And you always have to deal with the reality. You know, as you mentioned, there’s the sort of support and services model. That’s one that really had fallen out of favor, because many companies tried to adopt a red hat and very few succeed. Like, it’s hard to point to one that really succeeded definitively. And even my sequel, for example, kind of went more the open court route, which is interesting, because they were they were very early in the game, back in the early aughts. Right. So the the next very exciting one is Database as a Service. And obviously Amazon pioneered it, they’re very good at it. What Amazon typically builds for is the growth segments, not the enterprise segment. They’re repackaging open source technologies, and integrating them with the other services they provide. Trying to remove friction in terms of how you can adopt something without having to also become an expert at running it, maintaining it, all the one plus operations work that’s necessary. So you might pay a bit more than you normally would if you were running yourself. But once you factor in the fact, okay, we have to provide the hardware and the electricity and the trained operators, to run it ourselves in the TC to have a service, especially one where the company like AWS is able to have huge economies of scale, and be a better TCL. And Amazon can still make money on that is, in my mind, to my mind, the absolute way of the future for infrastructure. And for the exact same reason that the cloud, the public cloud is replacing private data centers, right? Fundamentally, a company like Amazon and Google and Microsoft can do cloud better than any company on the planet can do it themselves. Because they their economies of scale is just off the charts, right? There’s so much bigger even than a fortune 10 company with, you know, like the biggest fortune 10 companies might have 50 data centers around the world. But they’re shutting those down. Now, because even with 50 data centers, they can’t do nearly as good a job or nearly as fast in terms of how they can iterate internationally, as if they moved all of their application development teams into the public cloud. That same principle applies to infrastructure software. Like it’s maybe not quite as complicated to run something like cockroach DB yourself as to run your own data centers. But it’s pretty complicated, right? And so trusting a company like Cockroach Labs, to run it, not just for you, but for many other companies, and therefore, there’s economy scales, coming of scale in terms of, you know, what are the run books look like? What does the automation look like? What are all the different things that cockroach has to pay attention to? with, you know, 150 customers around security? Is that going to be better than any one company could do on their own? And the answer usually is yes. And certainly, I think it applies even more to a company like AWS, who who’s got, you know, 10,000 customers or, or more, to share with their customer candidates? You know, so that is the future.
Erasmus Elsner 20:42
This brings me to a very sensitive question in open source, which is defensibility, the cloud provider, whether it’s AWS or Google’s GCP. In the past, they’ve taken an open source project, and basically repackaged it as their own product. We’ve seen this with elastic and with other projects, as well. And last year, Around this time, Cockroach Labs decided to relicense to the Maria DB license, which is a, as far as I understand a time Limited License. Talk to us a little bit about what went into this thought process and how you think about licensing in open source projects in general.
Spencer Kimball 21:24
Yeah, absolutely. When we started, the open core model felt extremely defensible. I mean, I should just start by saying, I’m a huge lifelong fan of open source and feel like I’ve benefited tremendously from the model. And at the very least, I mean, there’s lots of elements of open source, right, some people conflate lots of different aspects of it. Only a subset of which are usually important to any particular interested party. Now, there’s, there’s community, there’s like prices and free beer, there’s whether the ideas are free, you know, in terms of, you can also whether you can port the code and build your own things, you know, all those things are important aspects of, of open source. And, you know, to a lesser extent or a greater extent, I believe in all of them. So, you know, doing cockroaches open source was absolutely critical. I think mostly because I would never use a database that wasn’t open source. And, and so it wasn’t an easy decision to move to what’s called the BSL which as you point out was, was developed for Maria dB. But of course, it’s separate from Maria dB, it’s not really Maria DB is licensed, but it’s a something that they worked out. And, as you said, it’s kind of it’s kind of a hybrid of a license. What it does is kind of gives you what amounts to patent protection. For a term, which you can set, it has to be less than five years, we set ours at three years. So for three years, there’s certain exclusions to the use of the software. And you kind of that’s something else you fill in, you fill in the term, you fill in the exclusions. And what happens is when the term is expired, for a particular release, it’s kind of rolling for every release, we released in April, then three years after that date in April, that that version would become a patchy, full open source. And then let’s say we did another one in October, then three years from now, over that particular release that was released in October would become Apache. So it’s this rolling three year window, what that gives us as a company is some amount of protection for our core, our core is very powerful. And we don’t want to start making our core not powerful. So it’s sort of cripple where, if you’re trying to use open source, we want our core to remain very powerful, we want it to leave pure open source at the end, we don’t want to, you know, I don’t want to squinted the ryzen and be like, Okay, well, we’re going to start putting more free features into the enterprise license, and you’ve never really gonna have a strong open source product, and you’re never gonna leave one behind, it’s always gonna be sort of tied up in commercial licenses. That’s what we wanted to avoid. And BSL is great for that. The other thing, you know, I mentioned is list of exclusions, if you keep that list, if you put zero things in the exclusion list, then you’d essentially have an Apache License. And the three year thing would, would be there, but it wouldn’t make any sense because it wouldn’t protect anything for three years, because there was nothing to protect. So that list of exclusions is if it’s empty, it’s equivalent to the open source license. We put one exclusion in there. And I think that’s also important. How many exclusions do you have in there, ours is just one, which is you can’t run cockroach as a Database as a Service externally. So anything else you want to do forking the code, you can resell our core, a shrink wrap software as licenses and provide your own support for it. You can modify, fork it Do whatever you want. And the one thing you can’t do is run cockroach sort of as a Database as a Service for commercial purposes, externally. So a company like Netflix, for example, could use cockroach core internally and provided as a database service as a service to their internal development teams. That would be totally allowed. So it’s very permissive. It’s just that one on exclusion and really, the way I think of that exclusion isn’t, you know, sort of an anti AWS RDS exclusion, and I don’t you know, Didn’t mean to just single out Amazon, although there, I think they’ve been the worst actor in terms of destroying the open core business model. But you know, it applies to any company that would take a take our core, and essentially, you know, be able to compete with us. And we just want that protection for three years, which I think is the is a reasonable window for where we can stay ahead on the innovation, and always make it Hey, Amazon wants to take something that’s three years old and run that RDS, no problem, but our version at that same period of time is going to be three years better, which, you know, that’s kind of puts the onus on us to keep innovating. And I think that’s important as well.
Erasmus Elsner 25:39
Another really interesting aspect about open source that is often discussed by more the salesy commercial people is that open source can really act as a top of the funnel engine and listen to a podcast episode with James Weitzman, who was a former director of commercial sales at Cockroach Labs. And he developed this the why try and buy method for buying and selling open source software. And what he mentioned there, which I found quite interesting is that he can oftentimes really skip over the why question and start at the try question, start selling a customer base that is really acquainted with the basic version of the product, talk to us a little bit about these benefits of the open core model,
Spencer Kimball 26:21
I’ll go further and say that you would hope that they actually get to the try aspect as well. And that’s something that we track every time, there’s a potential opportunity, and we put into Salesforce, some sort of commercial buyer, we’re tracking how what percentage of those opportunities have done their own technical evaluation already, because that adds a lot of time to the sales cycle and technical evaluation can take three months, easily. If they’ve already done that, then our job becomes significantly easier. And, you know, that’s, that’s a critical aspect of the open core model. And to the extent that’s working, you know, that’s pretty much that’s one of the biggest reasons, that’s when you’re open core model is really working. So the you want to get them all the way through try and essentially what you’d like, ideally, you would simply collect checks is the buy part. And you know, obviously, that starts the next stage of the journey where you’re providing the right support and professional services. They have, you’re unlocking the enterprise functionality that they may want to graduate to. And you’ve you’ve taken out the the y which is I would classify as education and to try, which is sort of proof of technology proof of concept. And that’s an open core has been for for as long as it’s existed. And that’s, you know, open source became the dominant model, not because I think people want to be ideas to be free, although I’m more of an idealist. And I feel that that’s, that’s, you know, definitely a factor for me, I think most people adopted open source and turned it into the dominant dominant paradigm, because it was cheaper and easier and faster. That’s probably the biggest one to adopt, and to deploy. Before I would take months of procurement and, you know, arguments with sales people and you know, procurement departments and msps, we deal with all that stuff, it’s pretty painful. With open source, you get to skip all that as the developer, but increasingly, the service based model, so not services, but you know, cockroach as a service, or databases service, that is a faster way to deploy, right, because you don’t have to download the open source, and then learn how to run it, you merely start using it, and somebody else is doing all of that running for you. So it’s faster. And, you know, it’s, I think, quickly becoming the dominant consumption paradigm. And so that’s something that now cockroach has to adopt as well, it really to, I think, be a big success in the 20s, then the 2020, you fundamentally have to provide that consumption mechanism. And I think, you know, the big opportunity for cockroach and for all companies that are providing Infrastructure as a Service, is to make that as frictionless as possible. And that’s something that we’re we’re working hard on I think, personally, the beauty of open source wasn’t just that it was quick to download it and try it was also free. And developers care about free beer and not just free software, free beer, right? They don’t want to put credit cards down in support. So to my mind, what you really need to do in the 20s with a Database as a Service isn’t just to make it really frictionless to try something out. But to but to take that a step further than just Hey, we’re going to run it for you to say, hey, it’s going to be free. In fact, it’s going to be perpetually free for for all but sustained usage. Right at that point. You start to graduate people into consumption based billing, and eventually into innovation. The biggest type customers into their own clusters, which are more expensive and have better enterprise features, enterprise SLA is around support and you know, fixing problems and so forth. So but that free thing is, is it matters. And I think in order to really capture developer mindshare, and the hearts and minds, really developers, you have to give them that better consumption model. And you have to make it so that they’re not putting down their, their credit cards. It’s just crucial.
Erasmus Elsner 30:24
So in the next section, I want to talk about the financing journey of Cockroach Labs. And I listened to this podcast again, of Peter Mattis, who said that you are really the natural born fundraiser, and that you’ve been crucial in leading all fundraising rounds of Cockroach Labs so far, if I look at your funding history, one thing that’s that’s quite striking is that you skipped the seed round entirely, the number of people call this a paper source, if you’re able to skip one critical financing round. And I assume you managed to do this because you you still had funds left from from selling your other company. And then in the summer of 2015, you raised your 6.5 million series A, really from the cream of the crop of the venture world, Sequoia Capital benchmark, first mark and Google Ventures. So talk to us a little bit about how this round came together. This must have been a hugely oversubscribed round, how did you eventually decide to go with these firms?
Spencer Kimball 31:29
Yeah, it’s interesting question. I mean, we were originally going to raise a seed, but the interest level was so great that it It ended up making more sense to raise more just faster celebration, and that sort of initial takeoff phase, how many people are you going to hire? How quickly can you start to develop the product in all those things mattered? Part of the reason we’re able to do that, as I mentioned earlier, is that we had some decent traction already with the open source project. And that level of interest for, you know, what was essentially something that was gonna be inspired by Google Spanner. So Google has also done a lot of education before us in terms of the paper that had written about Spanner, which was very well received. And there were VCs that were watching, okay, when’s the open source Spanner gonna show up? Right, and that definitely was something where I’d consider us to have written on Google’s coattails. And in a way like the best followings always a very good strategy. So what we ended up doing is we, there’s this really great early stage investor named Lenny press, who at that time was that asari, he then went to red point, now he’s at amplify, he has his finger on the pulse of basically everything that happens, if you haven’t had a mind, you really should have market. He’s amazing. I mean, he knows every research crew, but all the major universities, any kind of project that has traction, he is all over. He knows all the principles. He’s amazing. So he actually gave us our first term sheet. And, you know, we took that and we said, well, this is kind of fast and amazing. He saw the potential, and we decided, Okay, we probably should go out to Silicon Valley and find out, you know, other VCs are interested. And, you know, one of my, actually, my, my only first intern, Erik Norlander was at Google Ventures at the time. And you know, he also encouraged us like, hey, come talk to Google Ventures. And he gave us, you know, the names of some other investors and things. And it really was, I think, a driving force in telling us Okay, you guys, what you’re doing is definitely something that should get funded. And you should have a lot of success, fundraising. So we went out and it everything fell into place pretty quickly. And I think we were out there for several days. And like everyone we talked to, you know, maybe, you know, modulo a few naysayers was extremely sad, excited about wounded. So yeah, it was oversubscribed. Fundamentally, we included Google Ventures into Koi, because we just really liked the the people that we interacted with there. But you have to choose a lead. And for us, that was, you know, some combination of reputation, the sort of chemistry between because there’s gonna be the first person on your board, right? So you just want that chemistry to be excellent. And when we talk to Peter Fenton at benchmark, his, his belief in what we’re doing, and his, you know, obvious intelligence just really kind of blew us away. Benchmark has such a fabulous reputation, especially for, you know, getting that first, second and having a really good track record there. It felt like that was a pretty easy choice for us. And so yes, it came together very rapidly. Having that first term sheet, you know, if anyone’s out there looking like thinking that they’re going to raise money. It’s a great leg to stand on. So if you have that first term sheet, you go out and you make the rounds with the people that are You know, that you, let’s say, really you’re interested in. That’s a good way to quicken the process, and really drive sustained interest.
Erasmus Elsner 35:09
And I’m happy to see that you also made room in the round for Boise wretzky, from digitalocean, who was also a guest in this show before. And then you went on a year later to raise the series, a extension round where you brought an index. And I would assume that was Mike Volpi, who was leading the round there and talk to us a little bit about this next round and and what kind of milestones you had hit before raising that round.
Spencer Kimball 35:32
He had mentioned before, okay, let’s we decided to raise an A, because that was sort of investor appetite. And we raised six and change. And pretty quickly, it became apparent that that more money wanted to come in. And, and Mike Volpi was an introduction from Peter Fenton, which is, I’d say, a, you know, a better learning experience for me that the early investors you get, will often lead to the later rounds. You know, VCs have a lot of respect for each other, they have very little respect for each other. It feels like there’s kind of two polar extremes and, and to be extent that you start with good investors, I think you continue with good investors. And so, you know, Mike Volpi someone that Peter Fenton worked with, on many other boards, and they had similar outlook on the, on the open source and open core model and databases. And, and so, and a lot of trust, right. So that’s kind of like it really helps the entrepreneur in terms of how the following investors are already vetted, especially by someone on your board, right? It’s difficult, cold, if you’re going to say, on my second round, I know you don’t like this particular VC. But I really like them. And now you’re going to work together on the board together. Right that? Listen, I mean, I’m not saying that should never happen. But on the other hand, it does eliminate unnecessary friction if the board actually has a good working relationship. So you know that that definitely did factor
Erasmus Elsner 37:01
in, and then you raised a 27 million Series B in May of 2018, with redpoint joining, and then this year, you’ve officially become a late stage startup. By raising the series D from merrymakers new bond fund, it might be the reason that she was busy closing your round that she didn’t publish her infamous internet trends report, I think she published a COVID trends report. But how does it feel to be now officially a late stage startup?
Spencer Kimball 37:33
I think if you’re in an early stage startup position, you think, Wow, you really got to have it made when you’re late stage startup, but I can assure you that is not, not how it feels when you’re at a late stage startup. Instead, the pressure just ratchets. And, you know, you have different existential problems than he did when you were an early stage. I think even when you’re trying to IPO it probably feels like that, even when you just IPO it probably feels like that, that’s always from the inside things always, you know, have you kind of whatever your current set of worries are, they will expand to fill the available space. And it’s just the that’s just the fact of life, right? It’s true in personal life. And it’s certainly true when you’re running a company. So it doesn’t feel that much different to be a late stage company, although it does change the kinds of people that you can recruit to the company, some people that that fits their risk profile better. And you’re dealing with just a bigger company. And that that’s it cuts both ways, right? You certainly can get more things done. But well, there’s more inefficiency, you have more levels of management. Things you don’t change, you can’t change on a dime anymore. You can’t turn on a dime, right? You come more that aircraft carrier takes a day to turn around. You know, that’s that’s, that’s good and bad. So yeah, it feels it feels like we’ve made progress in the early stages, it’s
Erasmus Elsner 38:46
often still, you’re selling the vision mission. And then in the later stage rounds, many times, it feels more like you’re dealing with spreadsheets, how is it different from from a founder experience to raise one of those really late stage rounds?
Spencer Kimball 39:02
Yeah, definitely. There is a lot more attention paid to the numbers, because the numbers have become more meaningful, that I think only continues to go in the same direction. But I wouldn’t credit anyone that says there’s no hopes and dreams, no matter what your stages. I think even in a post IPO raise, like these days, these companies, I mean, look at Tesla, right there multiple. That’s not hopes and dreams. I don’t know what is right. And that’s, that’s a bigger multiple than anyone except for like a, we’ve just made $1 in revenue as a company. And you know, they’re giving us 1,000x something, and it’s a it’s an example. But, you know, hopes and dreams continue. And it’s always an important part in this sort of high growth market.
Erasmus Elsner 39:46
So in this last minutes, I want to take a real deep dive into the technology. Let me describe how I understand cockroach dB, if I would put it in technical terms. I would say that cockroach DB is a robust serializable lock Plus distributed database. And if I wanted to put it really simplistically non technical, I would say that cockroach DB is the atomic cockroach of databases. In order to get a better understanding, I want to go back to really the early days of databases, to the good old MySQL database, it’s obviously easy to deploy, it works well if you have fewer requests, but it doesn’t scale easily. And this is really where cockroach DB comes in, in my understanding, and so what would happen in the past, according to my understanding, is that you would engage in a process known as sharding. And basically, it meant that you process the data over a number of different nodes splitted into different pieces sharted However, this can get quite complex. And I heard you mentioned it somewhere else that Google Ads was basically running on more than 25 shards. And it was running into massive problems. This is also why the Google Spanner project emerged at Google, because this problem was really only encountered at scale. Talk to us a little bit about the good old MySQL days, and how cockroach has really built this open source version of Google Spanner and how this is, in many ways revolutionized how we can store data.
Spencer Kimball 41:12
Absolutely. I mean, the skill is a is a big one, right? One way I like to phrase it, for folks that aren’t technical is, hey, if you think you’ve got a $10 billion idea, and it used to be a billion dollar idea, but now I guess people find that to be, there’s been a lot of inflation, right. But if you think you have that $10 billion idea, like you simply you can’t use MySQL, not unless as you say, you want to do this manual shorting process on your own, which is very expensive. If you’re using something like AWS, Aurora, which is either running on Postgres or MySQL, this, this solution just doesn’t scale simply doesn’t. We’ve had customers, especially with COVID, where they were running close to the edge of the biggest node that they could with AWS, Aurora, and COVID came along and doubled, tripled their size of their business, and overnight, and so their Aurora databases just started cavitating huge stress and downtime. And so you know, like, the lesson from that is pretty simple. Like, if you’re really building for that huge success, why would you start on a database architecture that’s decades old, that doesn’t scale? Amazon’s built that because Well, a lot of their companies are, you know, smaller growth stage companies, and many of them won’t make it to that big scale, then. But from your perspective, as the entrepreneur, everyone expects, their business is going to have that ambitious win. And so you know, it’s really about why would you want to replatform down the road. So scale does matter. A, you know, you mentioned that it was over 25 shards, on Google AdWords was back in 2002, when I started, I think they started having big problems about eight shards. And that was just problems with having lots of different databases you were trying to talk to, and they got up to around 32. By the time I went off that project, by the time they actually placed my sequel, with AdMob, from AdWords with Spanner, it had gotten to more than 1000 shards. And my understanding is that Facebook operates with more than 100,000 shards of MySQL. And so both in the 1000s shard case in the 100,000 shard case, you’re talking about engineering centuries, maybe engineering millennia, over those decade, the decade plus that both of those companies experimented or utilize those architectures, where you’re essentially building a database yourself. You’re using MySQL at the lower level node thing, but then you have to build essentially a metadata base on top of that. And Facebook’s gone a lot further than Google, which is why I said engineering millennia. Imagine that, like 1000 plus years of engineering time. I mean, potentially considerably more. I don’t exactly know what the stats are for Facebook, but I do understand some of the complexity of the architecture they built. And it is, it’s mind Mind blown. Now, that’s not to say that something like cockroach can be replaced with a bill, I don’t think it could, Facebook is such a massive problem, they did kind of have to build that, you know, custom architecture. But there’s so much space in the spectrum between where you can get away with just having one node of Amazon, Aurora, and what Facebook is built. So you know, I think that, again, that 10 years of looking into the crystal ball that Google gave, they built big table, the first no SQL database, right, and then mega store and then Spanner as a progression of r&d and technologies that solve first and foremost, the problem of just burgeoning scale with Google’s use cases. And I feel like that is something that every startup that has plans, ambitious plans, should be worried about, right scale is critically important. This sharding thing is a mess. If the database can’t handle scale, and you try to handle the the application layer, what you end up doing is creating complexity, complexity scales very poorly, right? So you know, essentially, you’re saying, Hey, we’re not gonna use one MySQL node, one, Amazon Aurora node, we’re going to use two and we’re going to use four and eight. You kind of scaling up mean multiples of two. And that’s, that’s how we’re going to build things. In order to do that, because the database doesn’t handle scale anymore, you just got a bunch of different databases, you’re putting some customers on shard one, some customers on shard two. And then at the application layer, you’ve got to route appropriately. And if you want to do something between two databases, you lose transactionality, which is a guarantee the database gives you, if you want to query across the shards, you can’t either because there’s no meta database that can can, you know, the right term,
I can essentially ship the query in pieces to multiple nodes and then reassemble it into one. I mean, you could build something that does that. But again, now you’re starting to build a database instead of your application use case, a cockroach, by contrast, very simple. It’s a, it’s to every application that connects to cockroach cluster. And the cockroach cluster says 10 nodes. It’s not 10 shards to the application. It’s one database, but it’s 10 databases large. It’s a cockroach takes all of the complexity that any particular application, you know, that’s running some operation from an end user, it’s connecting into this database, talking to any node at once, and it gets a consistent view of the entire, you know, 10 nodes put together. So all of the transactionality works, no matter where the data is, even if it’s around the world, all of the querying works across all the shards and in in an optimal configuration or optimal fashion. Because the database engine itself is aware of where all the data lives, even if it’s geographically separated, and there’s latency involved in it. So you can make amazing decisions at the database layer if you start to increase the intelligence there. So that’s, that’s the primary reason of moving to a distributed architecture. I mentioned the other two. So there’s scale. By far, I think, that most top of mine thing in 2020, there’s also resilience replicating across data centers. And then there’s global or multi region, where you’re saying, Okay, well, we don’t just have East Coast, United States, we’ve got West Coast. And we want those both to be like, very minimal latencies, because we’re trying to create a game or something like that, a real time game or entertainment application or something like that. And so we want East Coast users to have their data replicated the west coast in case East Coast goes away. But we want primarily all of the operations on the east coast to be serviced on the east coast. So they’re very, very fast. We don’t have to jump 80 milliseconds round trip across the whole country. But that extends, of course, including the EU, but all of a sudden, now you’re like, Okay, well, eu users, both for GDPR reasons and for personal preference don’t want their data in the United States. In fact, the EU courts have just, you know, overturn this safe harbor provision in the GDPR. And that’s is increasingly true for Brazil and for Russia, and for China. And for Vietnam, like for Germany’s got more strict requirements, and South Korea has got requirements, I mean, the these things pop up like mushrooms after a big rain, right? I mean, they it’s just unbelievable. They’re everywhere. So that’s, I think, the critical problem to solve for the 2026. How do we how do we build global applications and services.
Erasmus Elsner 48:05
Let me dig in a little bit more into robustness and resilience. And one concept I came across when looking into this is the concept of synchronous replication, which seems to be a core feature of both Google Spanner and Cockroach Labs. And the way I understand it, it means that you basically need at least three nodes that are physically separate for this synchronous replication to work with synchronous replication means is that you need to, before you can commit either a usually a write or a transaction involving multiple writes, you need to get buy in synchronously from not just one node, but from the majority of nodes.
Spencer Kimball 48:50
In the cases, you mentioned three being sort of the minimum configuration for cockroach. With asynchronous replication, you typically just have two replication sites. And you don’t have to wait for the second one to acknowledge the right, it’s like you soon as just one response. And you can say I’m done. The advantage of that is you only have to wait for one to come back. And if there’s geographic latency, that can be very nice, because it says 30 milliseconds to do that replication round trip. That’s a it’s, you know, 30 milliseconds, you have to wait in order to get confirmation that you’re right is now persistent. The disadvantage to this is that you can write to the first replicated site, send off the thing asynchronously to the second replication site, say that the rights permanent to your user. And then let’s say that something interrupts that replication. So in fact, you’ve only written it to that first site, and that first site goes away. And so then your things failover and they start talking to that second replication, which never got the right now you kind of regressing back in time, you’ve lost that data. And that can cause incredible headaches. It can mean like dollars and cents, it can mean lots of user trust, it almost always means a big displacement of productivity within the organization, as teams have to scramble to do post mortems to find out what data might have been lost, but things that become inconsistent in the, in the, in the data schema, and, you know, writing sort of one off scripts to try to correct problems to refund money, you know, it’s it, it’s it can be a week of lost productivity. And many companies, when they lose a data center, you’re not talking about one application, that’s fine, you’re talking about, like, literally 50 application teams doing post mortems. So it’s, it’s bad for morale, and it’s particularly bad productivity. That’s something that that’s the whole point of doing this consensus based synchronous replication, synchronous replication just would not work if you had two sites, because you’d have to wait always for that second one to agree. If either of the two were down, you’d be completely dead. Right, because you have to wait for both ones down, you can’t, it’s not going to respond. So you’re never gonna get until it comes back, you’re going to be stuck. That doesn’t work. That’s terrible availability. So that’s why you go to three, or you go to five, the thing about having three or five, or seven, or whatever, is that you can just wait for the majority of nodes to respond. So you don’t have to wait for all of them, you just need two out of three or three out of five, which means that you can have one of the replication sites completely a wall, if you’ve got three, or if you’ve got five, you can have two whole sites a wall and five is a really interesting number, because that’s how Google runs AdWords now. So in other words, Google can now say, for their very valuable headwords property, right, where you really don’t want that to be down, they’re just going to lose money hand over fist, if that’s true, you want to make sure that you can have a plan database, or plan data center maintenance. So in other words, one of your five sites is gone now, because you’re taking it offline to say, replace some high level networking, or, you know, power PDU or something like that. So you have a plan maintenance. At the same time, you can have an unplanned maintenance, it’s like, okay, we took this thing out, it’s gonna be out all day Thursday. And oh, shit, someone took a backhoe through a fiber optic cable that’s connecting, it’s other data center. That’s also part of the replication, now you have two full data center outages, and you still have complete business continuity, because you still have three out of five, that’s like an amazing amount of business continuity. And like, that’s not the way Oracle and Golden Gate works like in the whole world is on Oracle and Golden Gate. So you know, what we’re talking about is like a big leap forward in terms of turning what used to be disaster recovery, into what’s now termed it resilience, like you want to make that transition, every business wants to make that transition, there’s of course, a cost, I mentioned it, right, it’s latency, you have to wait for the two out of three, and the three out of five, like you need all those to get back to you. So that’s the cost. But, you know, there’s lots of ways to make that cost bearable. You can create, you know, you can use just use replicas on the East Coast, the United States, for example. Or you can make sure that you’re using things that aren’t on the East Coast, or say, in Ohio, on the East Coast power grid, and then you have something that’s in, you know, Houston, and in the Texas power grid, and it’s something that say, in Utah, on the west coast, progressives actually close together, we’re sort of in the middle, you can get to them from the east west coast. But you also get them from Central in all of these cases, you’ve got all three power grids, the United States, and the consensus between any node and either Utah or Houston from Ohio, is actually pretty fast, because these things are kind of broken into groups and centers. So that’s a, that’s an interesting way to go about it. There’s lots of others, I won’t get into too much. But you do pay that latency cost. And that’s something that, you know, isn’t always palatable. But I think most companies are coming around to the idea that, you know, as long as you can keep that latency reasonable, this is a much better way to run operations in terms of keeping your business online, and your customers happy, and your engineers happy as well.
Erasmus Elsner 53:50
A related concept of distributed systems theory is the CAP theorem, which basically says there is a trade off between availability and consistency. How does this concept of synchronous replication fit into this CAP theorem? My understanding is that cockroach DB decided to go for consistency over availability. How did you take this decision? And what’s the technical considerations that went into this?
Spencer Kimball 54:21
So you mentioned the CAP theorem, which is widely misunderstood? For sure. You know, the idea that most people take away from it is that in building any kind of distributed system, you can either have consistency or availability. And I think when people think about consistency, it’s pretty obvious what you mean. It just means that the database isn’t going to ever return you the wrong answer. Like, you know, you hear things like Cassandra supports eventual consistency models, but eventual consistency means that at some point in the future, you’re going to get the right answer, but you know, you You might not get it when you go and do a read, not immediately, eventually you’ll get it. And that’s, that’s often really bad semantics. And it’s absolutely you cannot build a relational database, trying to use eventual consistency, you can build lots of other kinds of things. And certain use cases lend themselves naturally to eventual consistency. I’m not saying it’s a bad concept. It’s not you build a relational database. So that’s it, there’s sort of a fundamental mismatch there. So we really had to be consistent. The bigger thing where I think there’s more confusion is, is around availability. The CAP theorem has a very different idea of what availability is defined as than what a sort of an average operator would expect from a developer. If you think about running a system with high availability, right, which sounds like the same thing, it’s not the same thing. Like the captain’s availability is very different from the notion of high availability. But high availability typically means to people that we’re going to set some SLA, right, this database is going to have five nines of availability, that’s high availability, and you can say what actually needs to have seven nines availability. You know, that’s what high availability means. It’s kind of a kind of like your your probability of not being able to access the database and make forward progress. What availability means in the CAP theorem is whether any node can be disconnected from the others and make forward progress. So it’s, in other words, availability in the CAP theorem is just saying, if you want to let one node always move forward with no agreement from anyone else, then that’s available. In other words, you can create things like availability implies things like split brain, and like all kinds of different inconsistency problems. But it’s not high availability, you can take cockroach, which is consistent database, completely consistent, and you can give it its arbitrary amount of high availability. If you say you want cockroach to have five nines, then it’s really about what’s the probability that one of your data center replication sites goes away. And if it’s, if it’s very low probability, then you can probably just have three, if it’s, if you say that, okay, we want it to be even more highly available in terms of the percentage chance of not being able to use the database because there’s not enough reputation sites available, then you might say, okay, we can move to seven replication sites. And that’s going to give us, you know, seven nines of availability, because, you know, it’s kind of like, what’s the probability that with seven that you lose four or more. So that probability, basically, by increasing the number of replication sites, or increasing or decreasing the probability of a replication site going away, you can get to an arbitrary number of nines. So the CAP theorem doesn’t argue that you can’t make something highly available, that’s consistent. It basically says that if you want consistency, you can’t have any node, do it that whatever they want. But it’s a very narrow definition of the term availability. And it can really confuse people because I think the temptation is to say, Okay, if you’re gonna have a consistent database, then that means that it’s not going to be highly available, which is, is absolutely false. So I think the, the notion of availability in the CAP theorem is not really what people are looking for. And so it’s, it’s very misleading. I think, for the average person that hasn’t, you know, really sort of explored what it means in practice,
Erasmus Elsner 58:11
Maybe as the last question: Kubernetes. For the listeners, Kubernetes is the container orchestration system that came out of the Google Borg supercomputer project. And it’s not a natural fit with CockroachDB, because one is stateless, and one is stateful. Talk to us a little bit about how this integration works. And how CockroachDB has really benefited from Kubernetes.
Spencer Kimball 58:36
in Kubernetes, is excellent. It started off being stateless, as you say, but it has added support for stateful workloads. And there’s, there’s lots of different sort of concepts that go in there. And it’s constantly evolving. I will point out that board, you know, very early on in his life cycle supported databases as well. There’s there’s nothing incompatible with the idea of container orchestration system, or just sort of a deployment orchestration system, like the more general way of looking at it, and databases, or any kind of state, like the two things work fine. It just early on. Kubernetes didn’t tackle that problem yet. You know, it’s just things evolve, right? And so you kind of start with the easier problem, which is stateless workloads, and then you start to add things that can support state. So this point, Kubernetes, does support it. And in fact, we use Kubernetes. You know, for our managed service. So for cockroach cloud, we use it heavily. And, you know, all of our customers, not all of them, but the majority of our customers use Kubernetes or are very interested in using Kubernetes. So, you know, I think that fundamentally what Kubernetes is buying you is a way to automate deployment tasks that used to just involve a ton of hand tune hand rolled scripts, you know, bash scripts, Python scripts, Yeah, just things that, of course tool that came along like puppet and chef and things like that. And now with Kubernetes, this, there’s a more agreed upon standard that does more, is increasingly doing more that the whole industry has gotten gotten behind. I think this is one of Google’s most successful software development projects to date, because they did such a good job of making it industry standard by really getting it off the ground, and then inviting, you know, making it very open and inviting a much larger consortium of other companies, even some that are directly competitive with Google to contribute. I think that’s the right model for these kinds of things. And Google’s gotten a lot of mileage out of that. But you know, certainly Kubernetes would be how we would recommend anyone that’s self hosting cockroach to run it, because we now have a lot of experience with it. And it’s not necessarily better than other ways that you could do the orchestration. But again, that standardization, I think, is critically important.
Erasmus Elsner 1:01:03
Yes, Spencer, thank you so much for being with us here today. And I have to ask for my friend who saw you on Jason Calacanis his show last week, what’s your weekly workout regime? Because you look so fit and healthy, even during this crisis? And and where can people find out more about you and what you and Cockroach Labs is up to?
Spencer Kimball 1:01:26
So I’ll answer that last question. First. You know, if you want to find out what Cockroach Labs is up to, the technology blog is wonderful. So the blog we have just goes into all kinds of juicy detail about the innovations that we’re that we’re working on, in and you know, anything around fundraising, we have a lot of stuff in there around people initiatives, and how we’re tackling, you know, things like our interview process and open sourcing it, it’s just a lot of interesting things. So if that’s it, people want more information, I can’t think of a better place. I personally don’t have a Twitter, but cockroach, db has a Twitter. So that’d be another place to look to kind of want, you know, up to the minute updates, you know, about my COVID regime, or regimen that kept me in some degree of shape, you know, I do this thing called the seven minute workout. It’s kind of hilarious that it works. But I think what’s different about it from going to the gym is that when I went to the gym a lot, even when I had a personal trainer, this was way with a pre COVID that would be something I might do once or twice a week. At best, right? And you know, you’d work out really hard, you know, brand some serious calories, and you’d come away huffing and puffing, but he didn’t once or twice a week with the seven minute workout I never missed a day. So it’s that consistency, I think does yield results. And the beauty of it is that because it’s only seven minutes, it’s not hard to do. So you don’t feel like you do after the workout where you’re like, wow, I feel really good. In fact, I feel like I’d like to brag about my workout, you know, but you know, are you doing it every day? No, because it’s actually pretty hard and it would really turn you off if you were forced to do it every day. So it’s kind of interesting balance, like can you find a regimen that is pleasant enough that you can keep it up? So that’s one thing I do and then the other thing is I started this for like maybe the last eight weeks but I just juice until dinner so you buy these in my case it pressed juicery is that is the place it’s you know these green juices and I’ll drink three or three or sell them the you know from my body type at least it It keeps me in really good shape. And don’t know if it works for everyone, but the other unlooked for benefit and it’s really funny one is that every time I eat dinner, I am excited. And I never used to have my I’m excited, like well what am I gonna have tonight? It’s like it’s crazy. But you know the the introduction of that level of excitement around food is a gift that is surprisingly precious.
Erasmus Elsner 1:04:03
So seven minute workout consistently + intermittent fasting. Love it.
Spencer Kimball 1:04:08
Yeah, that intermittent fasting. It’s what’s what’s great about it is you know, the juicing keeps you from being hungry and not really fasting, right? You never like my stomach is dying here. I’m just gonna like pass out or something. It’s giving you some calories, but the beauty is that when you do eat your dinner, I actually feel pretty free to do whatever the heck I want. So I’m not trying to watch my calories at the dinner time.