Welcome to Unpack Pricing, the show that deconstructs the dark arts of SaaS pricing and packaging. I'm your host, Scott Woody, co founder and CEO of Metronome. In each episode, you'll learn how the best leaders in tech are turning pricing into a key driver for revenue growth. Let's dive in.

Scott: All right, Spencer, thanks for joining us today. Great to have you here.

Spencer: It's my pleasure, Scott.

Scott: For those of you who don't know, Spencer is the co founder and CEO of Cockroach Labs, the inventors of CockroachDB, and CockroachDB is a cloud native distributed SQL database. Actually, I would love to start, Spencer, to talk about the origin story of CockroachDB and, you know, what was the pain that you saw that you went to go solve, and how does CockroachDB solve that pain?

Spencer: All three co-founders of Cockroach Labs. ..we were at Google for about a decade, 2002 to 2012, and Google in that period, the OTs let's call, it was kinda like a microcosm of the global public cloud that we have today in terms of what they built and what they were imagining the proper infrastructure would be to exploit those unique environments. So for them, it was very low cost service that they're building their own rolling their own data centers eventually. And the reality for them in those early years, especially was that that hardware was very unreliable. The data centers were very unreliable. The earliest versions, or maybe they weren't quite the earliest.

They were maybe rev three or four or something like that. They were building servers with Legos in order to space components and provide some like room for heat dissipation and things like that. So, that probably gives you an idea that maybe some things would go wrong more often than a very well-tested and burned-in, you know, set of servers from a well-known vendor that you would use in a private data center for a bank, right?

So Google had low-cost infrastructure, wasn't reliable, so they built very redundant, distributed infrastructure. And when we were at Google in that period, we saw the advent of Bigtable and that kind of... yeah, listen, there's no one route for things like no SQL. These ideas have been around for a long time, but I think that paper really did launch quite a few invitations including things like Hbase and Cassandra eventually in Mongo, even if you wanted to squint but Google actually then quickly followed on BigTable and they called MegaStore, which introduced an idea of transactions to win more use cases that did have to deal with concurrency and correctness, consistency, and then that eventually led to Spanner. And it was the capabilities of Spanner, which people probably heard about these days because they wrote a big paper about it.

And then, it's offered now in Google's public cloud. Those capabilities did seem like a wonderful sort of omega point, right? That tied the best things together of relational databases, the more traditional ideas of consistency and concurrency management. And then also there's no SQL, which is extremely elastic, least scalable.

And with the advent of the Paxos family of consensus algorithms, It actually make them extremely reliable even across wider areas. It's all those ideas sort of came together into building the one system to rule them all for operational data. And that was very inspiring. When we left Google in 2012, it was just making it into production and the startup we did after Google, we kind of needed that same capability.

Needed, needed. Well, it turns out we didn't have it. And so we had to use DynamoDB, but DynamoDB without transactions 2012 to 2014. Well, we wished we had them. We spent maybe a third of our engineering time working around that problem. But the idea of Cockroach, to be an open source, fast follow on Google's internal technology, lived on.

And when we were acquired by Square, we decided to start working on that project for lack of honestly, something better to do. And that quickly gained some steam online. It's very interesting. You know, this is an open source GitHub project. There was a design doc, a design that got passed around Google and got passed around all over the place.

It were pretty interesting. Hey, this is the open source version of this cool thing with a ton of thoughts that Google wrote a paper on and VCs got interested. Lots of stars came onto GitHub, and next thing you know, hey, let's start a company around this. And that suited us. I mean, we'd done distributed infrastructure at Google, all three of us, to an extent.

We'd also done Gmail in Peter's case, and Google Reader in Ben's case. And then we worked on Colossus, which was distributed blob storage at Google. And in the end, when we left, we did this thing called Viewfinder, which is private photo sharing, which is where we obsessed about maybe having something like Cockroach.

Maybe we could build something. We almost started it but ended up with DynamoDB and struggled under that reign of terror. I mean, the right tool for the job. And we really welcome the chance to get back to distributed infrastructure. That's kind of where our sweet spot was. It's really nice to, hey, I got to use this tool now and I don't have the right one.

But it was nevertheless quite a... a return to the roots to go back to actually build one of these systems armed, by the way, with the very certain knowledge that it was necessary. And that was in about 2014 and it's been 10 years now that we've built the company.

Scott: That's awesome. I feel like the best open source stories it's like some insane itch that you just need to scratch and then the world also it turns out they all everyone's had the same problem and then you just grow like mad.

I'm really curious about maybe some of the decisioning around how to think about open source as a business. So at your root, like there's this open source project, CockroachDB, and then you started to build a scaffolding of a business around it. Maybe talk about those early days of how you thought about it.

Like, when did you start thinking about commercialization? Did you think about commercialization? What was the kind of early days and how has your thinking evolved over the past 10 years?

Spencer: Yeah, when we were starting Viewfinder and we mentioned we thought maybe we'd just build Cockroach because I'd written this manifesto on what was necessary and honestly didn't seem so hard when you squinted at it you know it's like oh you know it's like We'll just put this piece in and this piece in and this piece and we'll put them together, you know, like that's the only way to be a Software engineer that's an entrepreneur.

Like you've got to underestimate the true toil and cost. Otherwise, you might not do it. In that context when we're trying to build the ultimate private photo sharing to preserve memories and stitch together all the people that were involved, that was sort of our vision. We were like, Hey, this whole thing should just be open source, right?

And many things start that way. Or, you know, sometimes more often they're part of a huge business and then they get kind of like, Hey, let's open source this thing. And they throw it over the wall and then someone else might come along and then commercialize it. And this happened with Kafka, right?

I believe that came out of LinkedIn and Jay Kreps ended up building Confluent around it. And that was already a well established open source project that was getting some degree of ubiquity. And that's a great opportunity for commercialization. In that time frame, so around 2014, when we really got started on Cockroach, we had decided to raise venture money, right?

So from the get go, when we really got started on the project in earnest, I mean, it wasn't quite, there was six months before that where we were at Square and I and my co-founder, Ben, were working on it quite in earnest. And Square was letting us, and it was still, it's just an open source GitHub project.

But we were able to devote a lot of our time. That was actually maybe the golden era of my work on Cockroach. Cause there was just no constraints. I came to work every day at Square and I was like, how do I build the best distributed database? But I didn't have any thoughts of monetization. So it's not quite fair to say that from the very earliest days, I was worried about monetization, but certainly when we decided, let's go raise money and let's make a real stab at this.

And honestly, that happened when Square told us like they wouldn't support us, the two of us, working on it anymore. So they will, we can do something else. And there weren't honestly very many interesting things that were offered. And so that made the choice easier and we just said, let's raise money and do this. So, in that context, 2014, open source had already gone for a number of evolutions, especially when viewed through the lens of infrastructure... open source infrastructure being commercialized. You had Elasticsearch you had the Cloudera, Hortonworks, Face Off and those two companies eventually merged.

But boy, they beat each other over the head with the same underlying open source product, which is a very interesting sort of situation to be in. Nowadays, you've got the Kafka war, you've got Red Panda and Warpstream, which was acquired by Confluent. Like everyone's arguing about what segments of the market need what? Should it be, and this is maybe something to talk about, but, is it like a Snowflake model where you have all the pass through costs and it's a cloud service? Is it self hosted? Is that what bigger banks need or companies that are just finding their way, they're hybrid or whatever?

Or is it this idea that it's more like the way Databricks originally started where you bring your own cloud account. This is, by the way, how AWS runs everything in your account. You give them the account and they run the infrastructure in it. So that's bring your own cloud or bring your own data plane substrate.

And so these things are being constantly argued about, right? And ultimately it comes down to what does the customer need? And so then you have to understand your customer pretty well. In those early days, it seemed that open core as a business model was actually a solid bet because that's what was working better, honestly, for cloud era than it was working for Hortonworks.

Hortonworks was a pure open source product that they were selling support and services around. So a little bit like the Red Hat model originally, and they weren't, even though they were improving that code base quite a bit, it was all going back into the open source. It wasn't a core and an enterprise constellation of features around it that were keeping your customers on the hook to keep paying for a license and keep that predictability of revenue cloud era was doing it that way.

They had a whole string of enterprise features, mostly centered around making management easier. And that model was appealing, right? Many companies tried to go in the footsteps of Red Hat and very, very few succeeded. So, that early first generation of open source business model thinking had founded by 2014 and Hortonworks was kind of another, I wouldn't say a cautionary tale cause they did quite well and they IPO'd.

And they eventually did merge, but you could argue that it's cause there were two major commercial concerns arguing over the same open source core code base. It was a little bit strange. But we dove right into the open core model and it looked quite viable. But it didn't stay viable for long.

So I think that answers your question. We can dig into that...

Scott: Yeah, what made the commercial structure for gen one work? That point right up until 2014. In your opinion, what made it work, was it just simpler?

What about the internet at that point in time made that successful? And then, it sounds like there's a second generation, which is 2014. And then probably there's another generation, which is now. And so I would love to understand at a deeper level, like what's the underlying why for why that worked and then what changed in the world that kind of caused the monetization strategy or the commercial strategy to need to shift with it.

Spencer: Well, when you red hat, you got to go back to 99, really. And recall then that the penetration of Linux into the enterprise was non-existent on the grand scale. It was all Microsoft and different Unix flavors. So Linux, how did it work for Red Hat? I mean, I have to imagine it was the just incredible feeding frenzy of virtually the entire enterprise segment modernizing for the unbelievable fanning opportunity of the web. I mean, that was just the perfect confluence of factors that made it so that a red hat could build many billions of dollars of enterprise value because relatively clueless enterprises were embracing an operating system for the first time they didn't quite trust. What is this open source stuff? Like, I need a, I need a trusted advisor and guide to hold our hands of our organization. I mean, like that explosive potential... they were at the right place in the right time. And if you recall, there were a number of other Linux distros and companies built around them.

I think some of those did okay red hat had that first mover advantage or at least the first cohort of movers advantage and they nailed it, you know in terms of the branding and the professional mean and, just that it's ultimately the brand perception, the brand promise that they gave and they really leaned into that.

So I think that was a I don't want to say unique because these things continued to happen. I mean, maybe something like this could have happened with AI but by then, we're in a different world now, right? It does seem that we have a number of trillion-dollar companies that sit athwart the entire

ecosystem and they seem to be these gravity wells, right? That all value rolls into in the, not all, but 80 to 90 plus percent of the value accrues to the incumbents... they all have their respective information monopolies, and then, but they also, as an oligarchy have a not a stranglehold because there are plenty of other co-location facilities and things, but, the public cloud is a rich ecosystem. It gets richer by every passing day because of all the ISVs that build their products and services and launch them in the cloud.

And of course, everything that is an open source is just another of the hundreds of products that the clouds are offering. And so, they just have that incredible platform advantage that seems to gobble up most of what people think of as enterprise infrastructure and software that's being created new.

And so that certainly has applied to the mobile world and everything people have to do to support mobile apps. And I think that's part of what really made the cloud explode. And it's certainly been true now of AI and who knows what's next or what new revs of AI are coming. But you know, those early days of Red Hat, they haven't quite repeated, right? And so many companies, like I said, there was an almost ideological fervor that Red Hat's model could be replicated and in fact, should be replicated, and there was just like a golden age of open source donning. And it extended by virtue of almost like, it was a little magical thinking, but the power of open source could create so much business opportunity that the virtuous vendor providing the support would be able to ride a previously unrivaled wave of exponential growth and interest. And even if in a hundred users, one was a customer, that was enough. And there's some truth to that, but I think in the end, every company that succeeds goes up market.

And if your open source product is enterprise grade and you make it available for free, then people will use it for free. And so, how does that limit your growth prospects at the limit when you're going quarter by quarter to meet your goals and every single quarter. The roughly, let's say one quarter of your business that's up for renewal can decide that the 5 million they're paying you that year is optional.

It's like, well, that's maybe not going to work. So, you mentioned that there were like maybe two other ways, like one in 2014, one now, I think there's been quite a few and a lot of overlapping ones and different approaches to it. And we didn't take long, as I mentioned, to go from this idea of open core, which is very different from Red Hat's model and definitely was the flavor of the year of 2014.

We were forced to reconsider that in light of some moves that the cloud vendors are making. In particular AWS with Elasticsearch in particular, they'd taken sort of like this maybe a firewall that Elastic had created in the sort of commercial usage of their product. They'd say the core is hobbled in a production enterprise grade environment because it doesn't really have a very well fleshed out and suitable security model.

Like they didn't have encryption in flight. And that was not acceptable to enterprises. And that's where the money was. So, their enterprise offering was providing a encryption capability, not a hard thing to do. It's like the last mile or maybe less in terms of like, you've got the core elastic product, and then now you buy the enterprise feature and you can do encryption in flight, and then eventually encryption arrest, and they added other things. And so AWS just said, okay, well, we're going to build this for our customers cause they need it too. And last thing we're gonna do is pay Elastic for this because this open source product, most of the goods are already in there in the core.

And we'll just, I think they did it with another company, maybe Netflix, I can't quite recall, but they decided to just re-implement this easy thing. And then we'll open source that. Well, we're heroes, you know. All of a sudden Elastic's like, wow, we've been putting all of the R and D budgets of our business back into the product. Some of that goes into our enterprise stuff, but a heck of a lot of it goes into approving the core. And these guys added something in there, but now they're destroying us with the top line because they have a platform advantage. So that was eye opening to say the least.

It wasn't just Cockroach that had to change our approach. We didn't do it because we were being exploited by a competitor or a surprising larger competitor. They were a competitor in some cases. We did it just as a prophylactic for lack of a better term, like we didn't want to see that same thing happen as our product got better and really started getting more popular, which it did.

And what we moved to was a non-open source license section, but it was like, the closest thing to an open source license that was an open source that we could find, which is called the Business Source License. This had come from MariaDB, which is another database vendor focused on MySQL. And the way that license worked is that you could essentially, for some term of time, define some exclusions for use of the product, of the core in this case.

And then after that term, the core product, which had those exclusions under the BSL would revert to an open source license of your choosing. So in our case, we went back to Apache. That's what we'd originally made the core. Now the new versions of the core were BSL, but in our case, in three years, they've become Apache again.

So our core left a great open source trail after three years of a release date. And we had this great exclusion, which is very important to us, which is you can't run it as a database as a service commercially. So that was kind of like the anti hyperscaler provision so that we wouldn't unnecessarily face ruinous competition.

And many other companies did things like that, but ultimately you're trying to account for that kind of a competitive risk and give yourself some room to maneuver. We thought three years would be pretty good. Fast forward eight more years and you realize that three years isn't very long as a window to continue to innovate so that your three-year-old version isn't really a candy competitor.

And further, it wasn't just the hyperscalers or, named the big infrastructure platform that was going to be a competitor. It was actually the customers themselves that would essentially opt to use your core and just minimize the need or, build around the missing enterprise features just because of the sheer cost differential, right? And we'd always bet with an operational database that any serious enterprise would be allergic to running the operational database without the enterprise grade support. But we found that wasn't true, whether it was use cases that maybe weren't the true mission critical ones, or it was like, Hey, we can just hire people that can do the same thing that Cockroaches' support people can. That's going to be much cheaper than paying their license costs.

I think that mentality applies to the big tech companies more than other verticals as well. I think there's more evolution today. We recently changed our license again from this BSL and in relation to that risk. And honestly, I think you have to view what's happened in the context of why people really use open source in the first place, why it became so ascendant.

And then what happened since then? All right.

Scott: Yeah, I'm curious. Like, maybe you could talk a little bit about the recent change that you've made and how you see if you had to make predictions. You literally are, as a CEO, definitely making predictions about the future.

So how do you think, and you don't have to reveal any trade secrets, but like, how do you see this stuff evolving? What I'm definitely taking away here is that there's like a rich storied history of like open source, starting as this like very kind of platonic ideal thing and that like resulting in some pretty big successes in the two thousands and then, hyperscalers come online and they have a ton of market power that starts to shift the, like the viability of certain commercial approaches.

I'm curious where you see things sitting in 2024 and how you project out the next couple of years, it's going to change even further?

Spencer: The interesting thing about the hyperscalers, right? Is that their exploitation of open source didn't just work because they had a free product that now they could go and resell on their platforms.

It was the fundamental benefits of that delivery model, right? And that's why open source was ascendant versus closed source. Because think about the world before open source the kind of, before the red hat exploded and Linux did all these things and all of a sudden all the open source community around Linux and that had been around before Linux and they just kind of gelled in that in that world of essentially, I think it was mostly Unix at the time, right?

And it could have been FreeBSD and even plenty of open source on all of the big Unix vendors and things like that. You've tried to use closed source in those early days, boy, like stitching something together. It took a long time. It was very painful. There weren't communities, you had to read these gigantic manuals.

The tech support was horrible and slow and like new versions of software would come out very slowly. And so it was like this time of value that could be measured in months or years. It's just horrible compared to open source. That was just the way things were done. Open source, once people got a flavor of like, 'Hey, I can go online.

I can search like on Archie and then on the web and, ink to me and then Google. I'm like, all of a sudden, I get not just finding the software I need and the documentation for how to use it, but like every question that I might have, someone else has asked me, you know, that's where things like stack overflow showed up.

And that was, quite transformational and unleashed a a whole new wave. It was what made the whole internet take off fundamentally in the way that it did. And the time to value there could be measured sometimes in days and hours, right? So it was just not to talk to any salespeople and get like valuation licenses and go through a process before you even roll something out.

It could all just be stitched together and you could build like your website or your early versions of application web servers and things just like overnight. It was incredible, right? So it unleashed creativity, unleashed millions upon millions of new starts. And that's why open source ate the world, unquestionably.

It was the delivery mechanism of value, the time to value, that was reducible.

Scott: It was like a purely competitive thing. It's just that it was just faster, better, lower friction. It's in some sense, The native way to think about development at world scale, like hyper networked the internet.

So that's super interesting.

Spencer: And frankly, you had an environment right on Unix, on Linux, which is what people were absolutely moving to support all this web development. It was almost all free. That's crazy, right? So it's like orders of magnitude easier in terms of time to value and production. I mean, orders of magnitude less expensive, maybe.

At least in order magnitude, you still have to pay for the machines it runs on. You still have to pay for the people that have to figure it out when they download it. So it wasn't free, but it felt very, very, very, very free to the developers, right? 'cause they were already a sunk cost and they had their machines they were running on, which were a sunk cost.

So like the software is like incremental cost of what feels like zero. Just I'll be working all night and that you don't tally that up. So it , felt free. It wasn't quite free. What's changed since then? And this is what the hyperscale is really offering is that they've increased the value proposition beyond what open source was offering right with Managed services.

And so now with a managed service, it's definitely not free, right? But you're capturing those costs of how much time you had to spend on the complexity of whatever you just downloaded, figuring it out, stitching it together. And you're also capturing the cost of where you're going to run it. And you didn't always have a good place to run it back, back in the day.

And you run on your local desktop and then you'd figure out a machine somewhere and you'd be moving it back and forth. And the reality is learning how to download something, find the right thing, figure it out, learn how to run it. zero day, then one plus days of like maintenance and, you know, upgrading and security patches.

Whoa, now I don't have to do any of that. And I can stitch things together at a lightning speed. And yes, I'm paying and it's obvious, but the prices seem to keep going down because of like volume and just the, the inherent improvements that the cloud vendors were making in those earlier years.

That were just kind of like by leaps and bounds, they were increasing their margins and still lowering prices. I think a little bit of that downward pressure on prices doesn't seem to exist in the same way it used to. But like all those things led to a, okay, this is the new thing eating the world, it's managed services.

And that has profoundly, I think, altered the raison d'etre of open source, right? Now I think of open source now as thriving still, in particular in reusable components. Just think about anyone out there that's building software, like how many open source libraries do you use? That's crazy, right?

That's how you build software these days. And that is not going away, at least not from what I can see at the moment. That is extremely powerful. I think every company should consider open sourcing those kinds of reusable components. I think it's just supporting what we all use. And I do fundamentally believe in that.

I think that where we've come with infrastructure software in particular. is where direct to consumer applications have always been, right? It doesn't really make sense to make that, those finished infrastructure products free in the same way that it did for a moment in time.

Maybe that moment was almost two decades, but it was you're coming back around to this idea that You have two options, right? And this is always true with a direct to consumer applications. You can either hobble the core or the free trial or whatever whether that's time based or capability based, like hobble it. You've got to hobble it, right? Or you're going to have an unsustainable revenue base because people will just use your unhobbled product. For free, and they'll choose to do that because especially with enterprise software and infrastructure, the the kind of the extraordinary cost at scale will be optimized. There always comes the belt tightening and they're like, whoa, what are we paying this for?

Do we need that? Well, not really. They have an open source version. Why are we paying that? Because we need support. How many support tickets have we had? So that's the line of reasoning and it's inevitable, just inevitable, right? So, you, you either hobble, which some people have successfully done.

Like you can't scale this past a certain number of nodes or something. That's great. All right. But then You don't do something that we've set out to do with first principles. Our first principle is like, Hey, you know what? We want to start up like the mindset that we were in when we started this business, when we started viewfinder, even when we were at Google early days and before Google, we dot com, me and Pete. The two different dot com companies you want to use open source software as far as you can go. You want to minimize your costs. You want to be extremely scrappy. You don't want to deal with vendor conversations, like some, you know, especially the rinky dink outfit that has no money in it.

They don't want to take you seriously either. It's not worth their time. We wanted a startup to be able to use Cockroach and just go as far as they could go. Without ever having to deal with any kind of sales effort or that nonsense, and just have the real full power of the product so they could scale up and have a resilient database system.

Oh, but they don't need LVAP integration and they don't really need our support. They can use community support, but once they get big, they'll use it. Well, we found that that wasn't quite true. So what we do now, and this is an adherence to the principles we started with, which by the way, we're never that an enterprise.

say you know, financial services company or an enterprise, like billions of dollars of revenue tech company, would start to free ride on this. That was never the, we did not even contemplate that. Like, of course, these people need to run an operational database at scale with a competent support organization.

And when that proved untrue, we said, okay, well, what are the principles we cared about? So it's making sure that a startup can use us. That's very important to us. It's about the ideas being open. We blog about them, we explain them, the source code's available. That was also very, very important to us, and I think many people have benefited from that.

It's about making open source our components, like the reusable components that we use to, to put our system together that we think could be used in other kinds of systems but that aren't really central to, like, the finished product we're building. We have one called Pebble, which is like a RocksDB replacement, which is used by foundation DB, actually and plenty of other projects as well.

Those are the kinds of things like, how do we get the startup to have the right thing? But then ultimately, how do we make sure that there's a fair exchange of value at the high end of the market, which is where like we have to build our business. And that's what we ended up on. So we moved away from the BSL.

We moved to essentially a unification. Instead of core and enterprise, putting some features here and some there, you can't get these if you're small, but you, the whole things BSL. In the complexity of that and figuring out where things go and sort of sequestering them in the actual code was actually non trivial overhead for our engineers.

So we actually moved to unification, which is we are one product. It's an enterprise-grade product. It's the same for all of our users, whether you're a startup or the biggest bank in the world. And the experience is going to be the same in terms of using the product and getting all the functionality, and there's a lot of good stuff in that enterprise set of features. Like, for example while the two biggest differentiators that we offer are resilience and scale, those are in the core our third biggest differentiator and is being able to do things like global tables and global transactions and partitioning geographically. So you're domiciling data according to different constraints, but that is something that some startups actually want to start building.

But that wasn't available to them in in the core. So now what we have is we have one product. Everyone experiences the same way in its particulars. For any company that makes less than 10 million in revenue, they have an ability to use it for free 10 million in revenue.

So you get a yearly license when you self attest that that's true. Now, let's say you make 9 million and you start using it and you're quickly past 10. That's fine. You get it for that year, right? We're not trying to make it overly onerous. It's a self attestation. It's the honor system. Reality is that's not really where companies cheat.

In fact, we haven't seen companies cheat. I'm sure that's true in some countries. It's not true where we really do our business. Mostly, it's like we were giving away a free product and they were taking us up on it, and that was where our competition was coming from our core. In this model, we're achieving all the things we wanted to.

Our source code is still available, right? In fact, it's clear in the unification, and it's still ongoing. It's completely free to use Cockroach, and now Cockroach is a better product for all the companies in the world that make less than 10 million in revenue, which by the way is 99 plus percent in North America, right? So, it's the vast majority of everyone out there that's building something from scratch, certainly, and we still have quite a commitment to open source. We use a lot of it, and we make not just our main application source code available, but we have open source components like I mentioned, Pebble, that are being maintained by us and are used by other companies.

So that feels a good spot. We recently announced this in August and the reception was very, I'd say, neutral positive. There were some detractors do have some customers and prospects that were not happy about it. I'll be honest, it's a small minority and, to be candid, I do believe that some of that disappointment is a result of a long term intention to move to the core.

And, you know, that's understandable, right? It is understandable. On the other hand, it's never been our intention to give our enterprise product away for free to enterprises. Never. And so, to the extent we discovered that that was an exploitable loophole, that people would indeed exploit, that, that shouldn't be free riders, we had to adjust it, because ultimately, We need to stay in business for the customers that want to pay us.

And we have a lot of those. That's the vast majority of people are like, yeah, we get it. No problem. And even in the development community, like the hacker news article, right? There's plenty of commentary on that. It's mostly positive people. Yeah, we get it. Yeah.

Scott: Yeah. I'm really curious about that.

Cause I do, I think that's an awesome surprise. Honestly, that it's, okay, people get it. They're like, we need to stay in business. And actually for the majority of people, the product gets better and it's free.

Spencer:Yeah, that was actually a significant, I'd say, strain of thought in the comments.

It's just like, well, this is great because now I get to use all their enterprise features. So like longstanding users of Cockroach are like, wow, this is actually, they're giving away a better product now. And honestly, it's not just altruistic. It's an investment. We're investing in that startup business.

We're happy of aspirations to just have the scale that would require cockroach and we're investing in you so that you can be a customer when you succeed and that's a good quid pro quo,

Scott: It's like your ultimate, you're like aligning incentives well where the ultimate incentive is , look, we want to keep doing amazing stuff and in order to do that, we need to not be destroyed by a hyperscaler who offers our product for free or customers that just never up like kind of are always lagging three years behind. And therefore, we can't actually fund the R & D to make the product better over time. Do you think of that as like a philosophical change in Silicon Valley or in tech, obviously beyond Silicon Valley at this point, but is it a philosophical change? Is it a realistic, like a realism about what it takes to be successful in the limit for these tech companies?

Spencer: I think so. I didn't know exactly how widespread it is. I only have anecdotal evidence.

I can't. Say that I have a clear perception of the real zeitgeist here, but we saw that open source changed like very, very quickly away from the red hat model as it simply didn't work. People aren't just going to keep bashing their heads into a brick wall. Like, you either have participated in a company that tried to follow the red hat model and saw it fail from the inside, or you saw it fail from the outside.

And investors don't want to invest in it, right? And they get a little nervous. Like, why aren't you moving to open core? And now they're like, why aren't you just building a cloud service? Because you don't have to worry about this stuff, like open source, your library or whatever, and try to get people to use it, don't get sucked into the quagmire of some big customer that's offering you 5 million to support your open source thing, just build a cloud service.

That's the right way ultimately to do two things that are very, very important. One, that's the best way for time to value and long term consumption of a complex, increasingly complex product and not just your product, but all the things that have to get stitched together, right? And ultimately, people, understand the cloud pricing with a bit more empathy. We understand you're paying for these pass through costs in the cloud, right? Or you're, it's bring your own account and they're paying for it or whatever. But, you're running it for them.

There's this active value add that no matter how you're delivering it, they can't ignore it. It's not like I'm just getting a subscription license for you. You're paying support, which I don't use tickets for. This should be discounted 99% or more, right? It's like, well, we still are developing this software.

Yeah, but the thing works for me. You can't win that argument. Ultimately, it's just, it's not in people's interest to listen. But when you're delivering a service, It's very obvious that they don't have to have those DevOps people that have the pagers and all that stuff. And if you have the pass through cost, then it's a really nice alignment in the sense that you get to optimize those and improve your margin and pass the savings on to the customer.

At least a fraction of it that's healthy and you can lower costs over time. And that's a much bigger revenue base that gives you more flexibility. It's like a vertical Set of expenses that ultimately you can apply yourself to and figure out what's the critical path here. What do I optimize first in order to yield the most value that can be shared.

And so, it's like that time to value the ultimate cost over time. And I think that you just don't get the floor is higher on where like the ultimate discounting goes, even with the most incredible volume, which is important, right? So understanding your customer, right? If your customers are huge and they're going to get really big in terms of their usage over time.

If you were doing the old -fashioned way of delivering software, they're going to, really have a low floor in terms of what their volume pricing agreement suggests they should pay you. Whereas when you're delivering a service, well, let's say you even have the pass through cost like snowflakes model, like you, you're gonna maintain some kind of margin on that.

You're not gonna make your margin zero or negative. It's like, well, this is costing us money to give this to you, take away all of our costs for support and all that stuff. Or maybe that's factored in, but if it's just neutral, we can't build our business on this. So people understand that you're going to take a margin, even as you compress these factor costs and things.

And so that empathy is important, that there's much more alignment in there, and you're not having these ridiculous conversations where the vendor just does not understand why you ought to stay in business.

Scott: Yeah. One thing I'm curious about is, it sounds like the game theory in the 2010s kind of incentivize when companies have maybe an open core model with the hyperscalers.

Hyperscaler kind of unhobbles the software by taking in your example, the service and then adding encryption, which was like the differential between the core and the enterprise version. How do you see the game theory playing out now with with the really guys is a more pure competition where they're like, 'Okay,

there's this really great distributed global database. Okay. Now we actually got to go take those ideas and make them into production. And I can't just cheat on the core'. I'm curious, do you think that it means that there'll be fewer kind of AWS clones of given services or what do you think is the likely outcome?

Spencer: Well, I mean, I think we're already seeing that. I mean, the cloud vendors and even the kind of legacy competitors directly competing with Cockroach now and they're building their own products. We didn't give them the option to simply repackage our own and become the competitive nightmare that they became to some of these other companies.

But that doesn't mean they're not savvy competitors. My God, they are. They have a huge platform advantage. But ultimately, how do we survive in that world? Well, we've got to play to our strategic strengths, right? And again, what do our customers need? And so I think the huge area that's opening up right now is, and this is certainly true for a company like Confluent and it's very true for CockroachDB as well, which is our customers, they ultimately need to run in every kind of environment you can imagine.

And they also are increasingly starting to worry about what kind of risks are there to their business, for any use case, being too reliant on a single technical monoculture. So like, these are mission critical use cases that the world needs to get through a day. And they sometimes have regulators that are peering at their plans for continuity in the event of a massive cyber threat or a wide-scale geographic outage. By the way, these kinds of customers, they have private data centers. They want to go hybrid. They've got mainframes though. Like things are interdependent on the mainframe.

So they have sometimes have to start here and eventually move. They need portability between the clouds. They have to straddle them. They want to actively replicate across them. All of a sudden you're like, okay, this is a whole new Vista that's opening up. We have forced the cloud vendors who are quite capable of doing it, building their own competitive products.

Google, of course, was building it before we were, like, we fast followed Google for sure. But you know, there's the competitiveness of the different offerings. We have our own fast followers as well uh, only increases. That's fair. But you know, you have to keep innovating.

I mean that's the only way to have defensible growth and build a high growth ARR business, right? You need that revenue to renew and you ultimately want it to expand in these customers cases. And so you've got to continue to differentiate as any kind of business in a competitive space.

Scott: Yeah, that to me makes a lot of sense. And what I heard is this idea of... it's all well and good. The area of where AWS is very unlikely to be able to play is build a service that works equally well across GCP, AWS, and Azure at the same time, and yet the world, like the customers who sounds like they're choosing Cockroach, are the ones who are increasingly saying, 'Actually, I don't want to be isolated to a single cloud or a single region in a cloud'. And so in a way, the plane of competition is in some sense, outgrowing the capabilities of the hyperscalers are taking advantage of a fundamental limitation, which is they're going to build services that work on their product. Do you ever see a world where AWS is building a service that runs equally well across AWS and GCP ? Is that happening yet?

Spencer: It's going to, I guarantee it. Absolutely guarantee it. Because it comes back to like, okay, well, AWS built this business on the born in the cloud new starts, right? But that's obviously already changed and all the cloud vendors are going after the enterprise segment. It's where the majority of IT spend happens and the LTV on those customers is extraordinary.

They've been around for, let's say 20 years or a hundred years and they're probably still going to be around in 10, right? So there's, All the IT budgets is something like 80 plus percent in that segment, and a lot of it still is locked up on in legacy data architecture. So there's quite enough to crack there.

And people are very eager to do that. And by the way, those customers were eager to get into the public cloud and to use it where they need to and to modernize these very hairy, old applications and architectures. So there's tons of alignment there. The reality is there's a great, win-win in all of this. It's not it's not all dog eat dog competition. Ultimately the cloud vendors right now are still somewhat inward-looking, and you can probably see that just from the egress costs, which are egregious you know, egregious egress.

It's like almost 10 times the cost of like inter availability zone, like. Inter region is twice the cost of intra region. And the cost of going to another cloud is about five times more than that inter region cost. And it does not need to be.

Especially when you're paying for the fiber and using one of these other interconnects. And so that's just pure margin, as far as I can see. I can't speak exactly for what the clouds are doing under the hood. But, you know, ultimately, they think of themselves as walled gardens.

And that's what they've been optimizing. But I think the optimization function will change as they see that there's this incredible revenue, this tranche of new enterprise revenue that is addressable if they do more of what the customer is looking for and the customer, and by the way, it's not just , 'Hey, we want to run this system on other cloud vendors'.

It's also, 'We want to run this on our own systems. We actually want to run what you're doing on our mainframes that are sunk costs', like crazy stuff like that. So I think everyone will go in this direction. A lot of the clouds are constantly announcing things where they're doing things in your data planes and outposts AWS, right?

Kind of like, 'Hey, buy this rack' and 'Put this somewhere else' and you get AWS infrastructure. Google does the same thing. They'll have different names for these things, but it's going in that direction, right? It's just responding to the customer's needs. We're born that way. We've been operating our stuff in weird heterogeneous environments for a long time.

And there's a real benefit to that single-threaded focus of building a product that works very well across all these. So it is still a defensible differentiator, but my guess is in five years the clouds are going to have a path where you can Hey, this works best in our infrastructure, it's very portable.

Nothing's going to stop you from doing it. We, you can use AWS Aurora in GCP. We can make that portability seamless, like, I think that that vision is going to start to occur to everyone because again, how many additional hundreds of billions of trillions of dollars are going to be made available to the vendors that are unlocking the cloud agnostic and that's public and private as well, right? Substrate effectively to build your business. And by the way, like that substrate is something that regulators in certain industries are already looking at as a critical consideration. Like, are you capable of having business continuity?

If multiple zero-day exploits in one cloud's technical monoculture are exploited due to a hot ore breaking out, you know, what if all of AWS goes down because of some cyber threat that is quite sophisticated. This is absolutely a consideration for a chief risk officer and for the regulators that are worried about critical business infrastructure.

And most mostly there's not an answer to that, but increasingly there is

Scott: Super interesting. Actually, this kind of dovetails with something that I've observed, which is, Metronome was born in 2020 and so born in the cloud in some sense and Cockroach similarly. At least in Silicon Valley, the cloud has been the way of working since like 2013, But,

I am curious because I know you work with a lot of companies of various sizes and ages. Where do you feel we are in the adoption of cloud just across the world? In the sense of, are we 50% of the way through the transition? Are we 70%, 10%? How do you think about the companies that are yet to fully even ingest the concept of cloud as a key thing?

Spencer: Well, it depends on... It's very helpful to segment the IT spend market, right? Because the answer is very different depending on what you're looking at. I mean, I couldn't even tell you how it all blends together, but I am aware that for the last couple of years, at least Andy Jassy from Amazon AWS has said that something like, I don't know exactly what the number is today, but 90% of global it spend is still locked up on premise.

And how much of that is completely true. I don't know exactly how people estimate that. I assume it's just surveys of CIOs and things like that. But like, to the extent that there's absolutely a truth in that estimate that, and before I was saying how the majority of the IT spend is in this enterprise segment.

So, I imagine that you multiply those two percentages together and you're getting something like 60-ish percent. I think that's how much is available to still move to the cloud. And of course, the pie is growing, right? And most of the growth is actually in the cloud as well. I expect that the total cloud spend is going to be well into the trillions and growing.

I think it's something like almost 700 billion right now. But there's plenty more to come if that's only, let's say, 30-something percent of the maybe high 30s % of the total global IT spend then, wow! Okay. So you're talking about 1.5 trillion or something or 1. 8 trillion. And that's only going to grow, right? So clouds huge. We do see customers that are either repatriated. So they've gone private. The cloud is expensive, very, very expensive... the public cloud, that is. So there's some interesting landscapes going to continue to evolve. And of course, there's always the consideration of a different government perspective you obviously leads here on what the market power of these hyperscale is amounts to in terms of anti competitiveness. Those things are slow moving gears, but, slow moving gears in government regulation can turn into, I don't know exactly what the metaphor would be, but things can speed up , rather quickly depending on like changes in public sentiment and ultimately like a new kind of stream of thought in terms of what's fair, honestly.

Scott: Yeah, I was around working on web at Dropbox when GDPR hit and I can tell the relatively minor change. Very annoying to everyone, but quite a massive internal whipsaw and I think it completely changed the dynamics of competition. And so I hear what you're saying. It's like a regulator, like the, you can come in and make a relatively small change and have like profound second, third order effects throughout the industry.

I would love to close out by talking a little bit about how you think about open source and AI. Obviously you're not an AI company yourself, but as someone who's like deeply versed in open source, I'm curious... is your mental model of AI similar to infrastructure SaaS in terms of the dynamics with open source, or do you think it's different in some kind of fundamental way?

Spencer: That's a really good question. It certainly does seem different to me. I don't quite see it as the same. The foundation models clearly are like the finished pieces of software in the sense that everyone's decided they... you know, let's say from every meta and the smaller fast the new stars and things that, that don't have a...

A huge advantage in the quality of their models yet or the size of it? Mostly it's closed source right now, right? Or at least the weights are closed. How they build them or and that's what's important. It's not so much , the source code, it's like the architecture of the neural net and the and the training data and the fine tuning,

special sauce, right? I mean, I'm not that expert, but like, when I look at that, yeah, there are rough parallels to a lot of what we've been discussing today. In the dearth of open source models, certainly has given Meta a massive amount of leverage, right? As they got to the LLM foundation model race a little bit late.

I think that

a lot of that has been justified by safety concerns. I find that to be laughable, absolutely risible. I do not believe we're going to fume or doom. I think people misunderstand what this intelligence is and what it's capable of. Profoundly misunderstand it. I don't think that This LLM architectures are remotely capable of having the kind of agency that would lead to either of those outcomes or the kind of intuition that would allow them to exceed.

the fundamental patterns that are implicit in the training data that they have. They're simulacra, and there's not going to be anything else from these architectures. You can chain them together, you can do interesting things, you can fake stuff, but it's all just going to be like some combination of humans building complex heuristics and the patterns in the training data.

And you can do cool things with that. I think it's a trillion plus dollars of unlock. You know, it's maybe multiple trillions, it's hard to say. But they already work really well. They have great applicability.I think people fundamentally do believe in the acceleration and the fume and also the paperclip problem and like these things are gonna matrix us or whatever. I'm not saying they're disingenuous. Some of them are though.

Scott: Yeah.

Scott: Yeah, if you took the same sentences and you just took a religious spin on it and you fuzzed it, you'd be like This is indistinguishable in a lot of cases to something that like a cult leader would say or someone deeply religious would say And I'm 'Y eah, okay, it's this weird... it just feels like these hyper-rational people

and then they have these conversations. You're just like, okay, this just sounds like I'm talking to my crazy aunt Susie.

Spencer: Well, they are religious. Their religion is material reductionism. And they believe that by aping the firing of neurons, that they're going to create everything that humans are capable of.

Because I think they think that's all there is. And that's fair. That's a reasonable perspective in our society. That's what our society believes fundamentally. I don't think people believe there's a ghost in the machine that are hyper materialist in their mindset.

But I think they misunderstand consciousness because they're not really that cognizant of what's going on in their own minds. And they ought to spend a little more time meditating if you want my opinion.

Scott: I had not. Maybe this is obvious, but I had not made that connection.

But this concept of almost like AI religion being downstream of what you're talking about, the materialism. If this lack of understanding of the interiority of themselves is super interesting Spencer, I love to end just by asking about one thing that you're super excited about in the next one to five years for you and for your business . What's something you're super excited about?

Spencer: Well, actually, dovetailing on what we were just discussing, I am excited about the potential for AI. I've gone in some waves, I got super excited when 4.0 came out... Four... ChatGPT4 and it seemed like anything was possible. And yet, when you peel back some of the layers and you think about where this can be applied consistently and operationalized.

There were definitely significant impediments and that sort of cooled my ardor a bit. But I think when I look at Cockroach in particular, there's lots of complexity. And our users, depending on their persona, are running up against that complexity in different areas of the system.

Like the developer has their own inevitable friction, right? An operator is trying to keep the system up. can be quite clueless about looking at the signals until they become an expert. And those signals can be esoteric, and there's lots of them. And the same thing is true for a DBA. It's a distributed database.

It's not monolithic. New things apply. You got to learn a new system. And it's not that easy if you don't have a model for how it works at the lowest levels and how it's making networking calls instead of just doing things in a shared memory bus or whatever. I think AI has the potential to smooth that friction considerably, and that's something that we're investing in. And I am excited about that. I think that could ultimately change the trajectory of the business in terms of how quickly our customers can find their way to real production value building on Cockroach. And then how much friction they have just in the maintenance and operations and all those things lead to greater business outcomes in terms of expansion and additional use cases and ultimately cost, right?

Because some of our significant factors involve handling support tickets and the consultancy required to help people implement and scale and optimize. Very cool.

Scott: Very cool. I'm curious you have any tools or really interesting projects that you all have greenlit internally on this ? Is this stuff that's like early working, is this more stuff you're forecasting down the road?

How, has AI like changed things yet?

Spencer: Yeah, we're building some capabilities into the system right now. PG vector, if you've heard of that, which is essentially a vector data type and similarity search with secondary indexes and things. So that's ongoing.

That's table stakes these days for databases. We're using AI everywhere in the company but it's typically through third party tools. All of our SaaS vendors, of course, are blending AI into things. We're being mindful of exactly what our customers want right now. As opposed to what they need, as opposed to what they're not even asking for.

And it definitely turns out that there's more prosaic things that CockroachDB needs, than to automate the repetitive intelligence based tasks out of it. Like That's friction. It's not a blocker we have plenty of blockers still. And yet you have to do these things together, right? So we're ramping up our timelines and our thinking just because while I don't feel that the foundation models and the whole ecosystem quite there yet.

It feels like, if you're clever, you can still reduce friction today and it feels like it's getting better, right? So. I do predict it will get better.

Scott: I have one last question because I don't get to talk to entrepreneurs that often, but you've been doing it for 10 years. What is the secret to staying energized and focused 10 years in?

That's a great question.

Spencer: I've had to reinvent my role now. At least two times, two major evolutions. And if you don't find those evolutions that yield a new challenge and a new perspective, I think the challenge is very important for me. Everyone has their own. Psychological makeup that needs to be satisfied.

But if you don't do that, then you become very stagnant. And I think you become miserable, like what used to taste good is like ashes in your mouth, you know? And I've had those experiences. I used to be a developer. I was a developer since I was 12-years-old on the TI-99/4A and I, I never, not, didn't have a project until I was about 45 or so when I stopped working on Cockroach

and since then, I've had to kind of reinvent myself as really a CEO. I was a CEO for the whole Cockroach ride, 10 years, but at some point into it, I realized that the context switching out of code land where I could put in essentially 24 hours a day, if I could stay up that long and never get bored.

Like, that context switching was making me somewhat miserable in terms of having to do anything besides coding. And so, I just had to step away from it. And that was very disappointing. And it took quite a bit of of recovery in terms of changing my mindset and figuring out what kind of challenges could be effectively embraced to yield some of the same satisfaction that being a creator as a software engineer would present.

And then more recently, you know, when we had this big financial correction and we realized that the focus of our business just needed to be like... it needed to evolve the business fundamentally from something which honestly, since its earliest roots, had been more of like an R & D project. I'm like, let's build the very best database and we'll make it open source.

Yeah. We had some realities that came up and then when '22 happened and everyone, like you realize money's not free and these valuations have to be worked for, and the laws of gravity applied to every business, right? And that's just the new way to think. We had to get really serious about constraints and focus and winning.

And that changed my job as CEO as well. And I mentioned this a couple of times as we've been talking, but like the big unlock for me is why am I doing this job? Why do I want to keep doing it? And the answer is the customer, right? We make a really great product in many ways.

It needs to get better in many ways. And our customers are relying on us to solve their problems. better than we're solving them today. Make that less expensive over time ultimately help them win in their respective verticals. And we have to be around in 10 years. And so making sure that we're there for our customers, like having that more of a service-oriented mindset is giving me a raison d'etre that I think those previous two evolutions you know, it had dried up on me a little bit.

So that reinvention in service of customer. is something that, I think it's very important for the whole organization to believe in. I think that is a it's an evergreen value to champion as a business continues to mature.

Scott: Well, thank you so much for taking the time. I really appreciate it.

This was super interesting for me and thank you so much,

Spencer: Scott. Yeah, it's been a pleasure. One of the things that's important for being a CEO is you have to keep selling the vision. And I do still enjoy that aspect of it. So this was a great opportunity to do that. I appreciate it.

Scott: I must say that I'm now, I'm very inspired. I think what y'all are doing is amazing. And also just like, it's so cool to see. It's like 10 years in, but it honestly sounds like, I'm like, I'm sure your seed pitch was exactly the same in the sense of in the ardor and the passion. It still reads super strong 10 years in. So... Great. Thanks, Scott. Awesome. Thank you.

Thanks for tuning into this episode of unpacked pricing. If you enjoyed it, we really appreciate you sharing it with a friend. We'd also love to hear from you. Feel free to email me at scott at metronome. com with feedback and suggestions for who you'd like to see on a future podcast.

‍