Spencer Kimball Pt. 2: Competing with Big Clouds

Download MP3
Cockroach Labs CEO Spencer Kimball on the challenges of running DB as a Service.
  • Adopting BSL to defend against AWS
  • a "truly serverless" experience for Cockroach
  • A perpetually free relational database - what Gmail did to email
  • 4 scales for cloud: Free tier -> sustained throughput -> sole tenancy for scale -> dedicated multitenancy cluster (for the big enterprise)
  • it turns out that developing a multitenant hosted service also helps develop for large enterprise that wants dedicated multitenant service

Audio source: https://changelog.com/founderstalk/75

Blogpost: Why we're relicensing CockroachDB

Share/Comment via Tweet: https://twitter.com/swyx/status/1376470276918050818

Spencer Kimball: [00:00:00] The real challenge is how do you build and deliver cockroach as a service? And that's that's where I think the future of our success is going to be made or lost. And it's a, it's a transition right now.
The world's biggest companies. They want to run a relational database themselves. They want to self hosted. They want to buy software licenses. They might want to put it in private data centers or hybrid across private and public clouds. On the other hand in five years, even those companies much less, every other startup and high growth tech company, you know, they're all going to be using databases as a service in 10 years.
The entire world will be, so we have to not just win where we originally set out to build cockroach DB , the way that you might run Oracle or Postgres, or my SQL if you're running yourself. But we have to also now succeed with Amazon as a direct competitor and Google and Microsoft at these big clouds that are offering databases as a service and doing quite well with those businesses.
So how do we deliver Cockroach as a database as a service and effectively compete? There's a lot of really interesting answers to that question. It's by no means a foregone conclusion that a company like AWS, which is the cloud vendor incumbent really has as many advantages as you might think they have.

Adam Stacoviak: [00:01:17] I didn't do that thing because unless he pays for Cockroach cloud, you say. Cockroach cloud is the simplest way to deploy a cockroach DB and is available instantly. And here's the key on AWS and Google cloud. So what's your current answer. I'm sure over time, your answer will evolve, but what's your current solution to competing with these big players?

Spencer Kimball: [00:01:38] There's a number of different aspects to the successful strategy. And as you say, ours will continue to evolve. And one is you out innovate. And I think Google is probably the only of the cloud vendors that has a truly comparable technology. Amazon's better at repackaging existing open source. And, and part of that out innovating is you may have read, we made some license changes to the core of cockroach.
So we adopted something called the BSL, and that's a, that's part of how you continue to out innovate. It gives you a little bit of protection. Then there's. The idea of being multi-cloud or cloud agnostic, and that includes private clouds. So the deployment flexibility is extremely important to the world's big companies that have been around for a couple of decades and have lots of existing investments in data centers and high value use cases that aren't going to be easily moved to the public cloud.
And so that I think is incredibly important. You know, part of something that's worth touching on further is just how much innovation can be done in the database as a service model. And that's something that we're, we're pushing really hard on right now. Ultimately we'd like to deliver databases and with a lot less friction than they currently are delivered as a service.
Right now, when you get a database as a service, there's quite a bit of cost to it. I mean, even like a sort of production ready, encrypted instance of RDS, that's sort of the minimal footprint still costs you about a hundred dollars a month. Just a lot. And you're choosing the size of nodes where those nodes are located.
And there's a number of decisions that increase the friction of the process. We'd like to drive to a world where databases are, are truly serverless. And the sense that when you get a relational database, it's something that you can pay for exactly what you use. Not worry about what kind of machines, how many and so forth, or even where they're located.
You just get a database and that database is truly capable of global operation. Hey, if you only use it, the East coast of the United States, great. You want to add the EU? That's extremely simple as, as simple, essentially as setting a different value in for a column and a table specifying what region the data should be stored in, or whether it should be global as an example.
And further, we actually think that price is a major impediment to using something like a relational database as a service we'd like to make these things perpetually free for developers for a pretty generous tier. So think about what Gmail did in 2003, where they're effectively making a gigabyte of email free.
And you know, at the time you had, it was unheard of Yahoo. Yeah. It was like five megabytes. What you got before, which it's filled up with one MP3, somebody sent you or whatever, a couple of photos. So this is a huge innovation, obviously just set a new standard for what web mail should feel like. And while Gmail is free, if you want a hundred gigabytes, you pay for it that, that extra storage space.
And that's exactly how cockroach cloud is going to feel to a developer. Like we want to make perpetually free relational databases that are. The seed of an extraordinarily powerful production database, something that can scale to run, you know, retail banking for the world's largest banks that has geo replication for a high level of resilience.
And that is capable of truly global operations. So that even a startup could use the free tier of cockroach cloud and you know, store data for customers in Brazil, in Brazil store data is for customers in Japan, in Japan, right. And give them a local experience. That's how big tech build services and applications.
We really want to make that, so that every company in the world, even every developer, like even in a hackathon can build that way. And it's, you know, ideally easier to build that way than it is to stand something up yourself in a single availability. 

Adam Stacoviak: [00:05:23] That's ambitious for sure. Because one of the hardest parts is adoption and you're guaranteeing that by.
Enabling that perpetually free tier that's generous so that you can tinker in a hackathon or scale your enterprise. And it's the same coverage for cloud, right? It's the same cloud. It's not, it's not like a different version of it. It's the same version 

Spencer Kimball: [00:05:44] regardless. Yeah. We want that to be a very continuous product experience.
And I think the journey that is most evocative for me is, you know, you're starting a company which, you know, I've done. Viewfinders the canonical example I was using my head. How much easier could we have made the viewfinder experience? And that's just great, right. To have that experience, to, to make product decisions is, is pretty fundamental.
But you know, the idea would be a cake. You know, Hey, you want to stand up your database, your pre-production, but you know, you have developers that are pinging it and so forth. Certainly don't have to pay for that. Right? You don't have to have this big server that's sitting there. That's almost completely idle for months.
And then you launched the first version of your software. You get something into the apps, or maybe it's in test flight or something, and you have, you know, a hundred beta users that are, are poking at it and so forth. You're still under the free tier for sure. Right? It's only when you really scaled to get more product market fit and you start having sustained high throughput, then you start to get into overages and you can pay for exactly what you're using over the free tier threshold.
And then eventually if your startup continues to succeed, you're going to want to move to sole tenancy, a dedicated cluster, as opposed to the, the cockroach cloud free tier and the overages where you're sharing a multitenancy cluster with other users. So for InfoSec reasons so that you don't have noisy neighbors and you have a very guaranteed.
Throughput exactly what you expect and there's no sort of variance in terms of your latencies and response times and so forth. And also in order to truly scale to big sizes where the, the cost is more  economical, that's where you'd move to the dedicated cluster. And there you can scale to, you know really as far as your ambitions.

Adam Stacoviak: [00:07:28] Yeah. It's very similar to the, the VPs analogy, you know, where you might be in a virtual private server, you know, you're maybe have some noisy neighbors to use your example, but if you can go beyond that, maybe you get your own dedicated virtual, private server where you're not sharing, you're not in shared resources, you have your own dedicated, that seems like a very similar analogy.
So if you get that from that world, then you'll get that in the database world, 


Spencer Kimball: [00:07:53] the church that's exactly accurate as an analogy. And what's. Really wonderful about this capability that we're building. The thing of it is virtualizing a big cockroach cluster and allowing many tenants to share those resources.
That's also something that's extremely interesting to big enterprise customers. They would like to have their production use cases also run on a multitenancy dedicated cluster. So one of these big clusters that, you know, we might have a public, you know, any developer can sign up with their GitHub OAuth login.
But you know, you might deliver that to a major financial services institution as a dedicated cluster, but their internal teams get to share those resources in a pool. So they don't have to say, okay, for each one of these production use cases, we have, we're going to have completely dedicated hardware, which we, you know, have to make sure its size so it can handle our peak throughput.
That's a lot of wasted resources over a hundred production use cases. If you can pull all those resources and allow the. Overages from one to use additional resources from others that might not be at peak for, but then you get to have much more efficient resource sharing. So what we're building for the public at large to really connect cockroach DB to the large audience developers out there in the world is also something that is extremely valuable to the high end dedicated cluster companies and customers.


Spencer Kimball Pt. 2: Competing with Big Clouds
Broadcast by