Cockroach Labs has created a clone of Google’s Spanner geographically distributed database, and it looks like adoption of the CockroachDB database is starting to ride up the blade of the proverbial hockey stick and is moving quickly towards the much steeper handle.
According to Spencer Kimball, one of the company’s co-founders and its chief executive officer and importantly one of the ex-Googlers that created software at the search engine giant and also used Spanner, the company started selling CockroachDB support contracts last year, and in the first quarter of this year it did a little more business than it did in all of 2018, and in the second quarter it almost doubled the business it was doing in the first quarter. Companies that tried CockroachDB in a proof of concept and then a net new project are coming back and re-upping for 3X, 4X, 8X, and sometimes 40X the subscriptions, and at the same time the company has 50 paying customers out of tens of thousands who have downloaded and played with the software. That base of paying customers is growing very fast, too.
What is driving this growth? In a word: Oracle. Or more precisely, frustration with the high price of the Oracle database and its associated systems programs to scale it out as well as the lack of good support for the Oracle database across many of the big public clouds. In a world that is increasingly hybrid – spreading workloads across on premises and public cloud infrastructure – and multicloud – wanting to run it across many public clouds to avoid lock-in – Oracle is a big target of all the upstart database makers. But the game is more complicated that just targeting Oracle. It is about picking databases that don’t lock customers down at all, and that includes services such as Aurora from Amazon Web Services, Spanner from Google, and Cosmos from Microsoft.
We had a chat with Kimball about what is going on with relational databases and the inflection point that is starting to favor the most open and portable of them.
Timothy Prickett Morgan: Hybrid cloud is on my mind a lot these days, and I have been arguing for quite some time that all of the big players are going to have to offer on premises versions of their infrastructure if they hope to get customers beyond the startups who will never want to run their own datacenter and will resist that until the very last second they cannot – should they be so fortunate as to outgrow the relatively expensive public cloud infrastructure. What is your approach to hybrid cloud – and we should probably talk about multi-cloud too while we are at it – when it comes to CockroachDB?
Spencer Kimball: As it turns out, we have been focusing on providing CockroachDB in a very sort of multicloud, hybrid environment. There’s sort of two angles to that. One is the managed service offering, which currently spans two clouds and that’s something that you know we can deliver fairly seamlessly for any company and there’s very little they have to do. But the main focus of our most recent announcements is integrations and partnerships with a really wide variety of different cloud platforms. There’s Google Cloud Platform, Amazon Web Services, Microsoft Azure, IBM Cloud, Oracle Cloud, Rackspace Cloud, and Digital Ocean. What we’re looking to do is to establish CockroachDB as a solution that works across many environments, and this is what we see as a big demand in the marketplace for right now.
TPM: Hybrid, multicloud is pretty much about the only thing that large enterprises want at this point. I find it ironic that there’s such tension in the public clouds. There is often very good functionality within a particular cloud for specific functions such as databases – BigTable and Spanner at Google, Aurora and DynamoDB at Amazon, Cosmos at Microsoft are great examples. They work well on their indigenous clouds, but enterprises want their software to span multiple clouds and on premises. It’s just funny these companies are going to all this effort to create great technology, and some of the biggest spenders are not going to be able to use it. What does that mean?
Spencer Kimball: That is just it. I’m sort of unhappy that Google hasn’t done it and that Oracle hasn’t done it, but on the other it seems painfully obvious from a strategic perspective when they have a competitor like AWS, which is the big incumbent, that they’re providing their proprietary solution only in their cloud. At the very least, they ought to be providing proprietary solutions across all the public clouds.
The big change in the marketplace right now – and you hit the nail on the head – is that consumers of the cloud were chiefly growth stage companies so far. Now there is a big shift in the market where massive Leviathans, with huge market capitalizations and budgets are wading into the public cloud. Some of them might have the big toe in the water, some of them might be ankle deep, and some of them like Capital One are waist deep. But by and large, they have not entered this pool and when they do it’s going to be a huge wave that is just going to double and triple the size of the current cloud market.
These companies they have well-known ways to index risk, whereas growth-based companies are really denominated in terms of their survivability and their time to value for customers. With these bigger companies, it’s about mitigation of more old-fashioned risks, like vendor concentration risks.
TPM: Large enterprises are getting comfortable with the idea of the public cloud, but what happens when they actually are comfortable?
Spencer Kimball: What’s crazy about the cloud is that even though it’s much cheaper, incrementally, to run a workload in the cloud, the cloud makes it so easy, it’s so fast to do, that companies actually end up spending more money. So by workload or by use case or by service that they add, it’s cheaper than what they can do internally but they’re able to do five times as much. So large enterprises wading in represents a huge expansion in the market, too.
When you think about what would probably be the biggest outlays for a big company in the past – and the most fraught vendor relationship – it was Oracle. The database spend was massive and remains massive. The market size per year for relational systems Oracle comes to around $50 billion, and the cloud is expected to be over $200 billion this year. So the idea that companies are going to, without any caution, put that kind of spend into one vendor is you know based on the past with Oracle, Microsoft, and IBM. These customers are actually wary. Big companies have a longer time horizon. They are going to be stuck with their vendors for at least ten years. Early stage companies don’t talk about ten years, they just have to survive. They don’t want to learn new platforms, they already know AWS and they will just put all of their stuff on AWS because they just have to survive.
TPM: These are very different kinds of companies with very different needs, but they are all going to be sticky just the same in the end.
Spencer Kimball: Maybe not. That’s what is changing, and that is the inflection point in the market. And now all of a sudden, companies, even the big ones, on a practical level, will be able to use multiple clouds equally, where there are things running across Azure, GCP, and AWS and they can flip the switch and leave AWS. Almost nobody has that kind of a system today because it represents a massive amount of engineering because the cloud platforms are so different. But things like Kubernetes are helping to make it so that they’re more similar than different. And nevertheless, these companies, even if they have most of their spending on AWS or GCP or Azure, they will want to make sure they still have options. They want to avoid the hard lock-in.
TPM: The irony is, as I was saying, that the big public clouds go through all this grief to create these really elegant systems for storage and database, and they’re not all the same but they’re all trying to do similar kinds of things in terms of abstracting networking and storage and compute in clever ways. And when it’s all said and done, they might just end up making themselves into giant whiteboxes with extra goodies that no one can actually use unless they don’t mind being stuck on one particular cloud.
And you know, that might be OK. There might be 30 percent of the market by customer count or revenue, however you want to slice it, that is willing to go all-in with any cloud and just use whatever they got. But I can’t see that that’s going to be the case for the majority of the market. Companies are going to want to use CockroachDB, a clone of Google Spanner, rather than Spanner on GCP, to try to mitigate risk. You’re going to try to use a variant of MySQL. Large enterprises have been burned so many times, starting with open systems back in the RISC/Unix revolution, and they started out on mainframes five decades ago. Now, they have a change for a variety of infrastructure suppliers and a consistent software stack across it.
Spencer Kimball: You can see why the cloud vendors building their own databases and datastores. They get so much more money out of it – and also to your exact point, the 30 percent that might not mind the lock-in. I think right now that number is more like 90 percent. These startups have all of their spend in the cloud, and in one cloud, and that is so by definition.
But you know that’s rapidly changing and the balance could be completely upset. So the question is: What will the cloud vendors do? Are they going to try to protect what they have by putting better and stickier services together that only run on their cloud so that they’re a more attractive option? Or do they figure it is not worth protecting the cloud infrastructure business, the higher level services have better margins so let’s guarantee our products work across all of the clouds. This would really apply to Google, who puts more money into product R&D. And this would also apply to Oracle, of course.
TPM: Well when the Anthos Kubernetes stack appears on AWS and Azure, then I will know the situation is really changing.
Spencer Kimball: It seems like that sort of thing is the future, that what the clouds become, what they offer, is going to become increasingly commodified.
TPM: Precisely my point. A public cloud’s raw infrastructure is just the new whitebox – and it is just a really big one. They can make the money in the short term, the margins are good. But in the long term, who knows?
Let’s swing this around to how CockroachDB is doing. What’s going in terms of the ramp for paying customers?
Spencer Kimball: Since we talked a year ago, the narrative that is emerging is that there’s a big gap in the market.
Most of the Fortune 1000 have been using Oracle over last couple of decades. But they are looking at the public cloud exactly as we have been talking about it. What the public cloud is offering you know as an alternative to Oracle, it’s not really what they want. For one thing, if we just take something like Spanner, it’s not SQL enough, even if they are fixing that to a certain extent. If you take something like Aurora, it has MySQL and PostgreSQL compatibility, both of which are good systems, but it is not really as good as the Oracle database and it is really a kind of a step down in terms of some of the things you might need in terms of Oracle RAC, for example, which is a fundamentally more scalable system than what AWS is offering with Aurora at the moment.
But the much bigger issue is that large enterprises that are thinking about moving into the cloud don’t want to be tied to a single vendor and that’s what Aurora is, and that is what Spanner is, and that is what Oracle on Oracle Cloud is. So people don’t want to be only on GCP, or only on AWS, or only on Oracle Cloud – and that is the worst by far – because it constitutes a vendor risk. So that is a huge gap in the market. These companies need a database that understands the cloud, that works with the cloud, and that works with those next generation workloads they are going to build for the cloud. And we actually have the product for that that fits that technical description, but also works in all of the clouds and works hybrid and multicloud, too.
That’s another fundamental piece to this puzzle. These big companies – even if they want to move everything to the cloud – they also realize that practically speaking that’s not going to happen for five years or seven years or even ten years. They have to sunset the datacenters they have; there are sunk costs there. They have legacy systems they have to keep running, they can’t easily move mainframes, and so on. Whatever new technologies they employ, they would like will embrace something of a consolidation. That means the new technologies can’t just work on one cloud. They have to work on all of the clouds and it also needs to work on premise. That ability to do hybrid is a big differentiator.
TPM: I thought that from the beginning that we needed that and that AWS would have to do it and Google, to their credit, figured it out and actually has done private, managed, local Kubernetes. But there is no official private Spanner from Google, but it looks like CockroachDB could do it in a pinch. It is probably better to run a database like CockroachDB across the public clouds and on premises and keep it all as much the same as possible.
Companies are paying so much for Oracle databases including RAC and GoldenGate cluster extensions that it is the obvious target.
Spencer Kimball: When you look at competitors like Spanner, like Aurora, like Cockroach, you really have to price that per core initial outlay for the Oracle database stack at $100,000 because you need GoldenGate, which is not as good as what Spanner, Aurora, or Cockroach are offering, and you need RAC, which is not as good as what Spanner or Cockroach is offering but is probably better than Aurora. It’s mind blowing.
TPM: And even if you get a 50 percent discount, you’re still like really sore after getting that bill.
Spencer Kimball: And Oracle has these really byzantine contracts that make it hard for you to ever dial back down your spend if you try to migrate off, and the audit process can be very painful for companies as well.
TPM: Can companies actually get off of Oracle once and for all? Maybe the Oracle stack is just as sticky as MVS plus CICS plus IMS plus DB2 was 30 years ago on the mainframe. So when can companies ever be free of Oracle, and do they truly want this?
Spencer Kimball: That’s a good question. And I think the answer lies in the cloud transformation.
The cloud is a fundamentally new computing platform that every single company in the world is motivated to embrace just because that’s the only way to compete effectively. So that in order to actually use the cloud, not just do a lift and shift, you have to embrace new software engineering methodologies and infrastructure tools and so forth. All the things in concert all allow you to start to build new applications faster — like considerably faster. In some cases, I would say twice as fast, three times as fast. But as I said, you actually end up spending more but you can make more money rolling out more software behind more products. So everyone is moving to the cloud, but in order to really move, you have to re-architect. And it is that re-architecture that makes it so Oracle can lose – finally.
TPM: Maybe Oracle will have to cut price? Stranger things have happened. . . .
Spencer Kimball: For what it does, Oracle’s database is very good software, and it is very expensive because it is very good software. Oracle did very smart things competitively, but ultimately what Oracle built was a database for a previous era of computing. And Oracle has made some hand-wavy motions about a cloud, but Oracle has not fundamentally changed the architecture, and its idea of the cloud is putting the Oracle database in its own cloud. And one thing I know that’s never going to happen and that companies that currently have a vendor relationship with Oracle aren’t going to start giving Oracle their cloud spend without second thoughts. I mean, the cloud spend is going to be 10X what the Oracle database spend was. So they are going to now put 10X times as much money into the Oracle relationship? That seems impossible.