 From the CUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. Hi everyone, this is Dave Vellante and welcome to this CUBE Conversation where we're going to dig into the area of cloud databases. And Gartner just published a series of research in this space. It was really a growing market, rapidly growing, a lot of new players, obviously the big three cloud players and with me are three experts in the field, two long time industry analysts. Mark Stamer is the founder, president and key principal at Dragon Slayer Consulting and he's joined by David Floyer, CTO of Wikibon. Gentlemen, great to see you, thanks for coming on the CUBE. Good to be here. Good to be here, Dave. Mark coming from the great Northwest, I think first time on the CUBE and so it's really great to have you. So let me set this up and as I said, Gartner published these three giant tomes. These are publicly available documents on the web. I know you guys have been through them several hours of reading and so good nighttime reading. The three documents where they identified critical capabilities for cloud database management systems and the first one we're going to talk about is operational use cases. So we're talking about transaction oriented workloads, ERP, financials. The second one was analytical use cases, sort of an emerging space to really try to, the data warehouse space and the like. And of course, the third is the famous Gartner Magic Quadrant, which we're going to talk about. So Mark, let me start with you. You've dug into this research just at a high level. What'd you take away from it? Generally, if you look at all the players in the space, they all have some basic good capabilities. What I mean by that is ultimately when you have a transactional or an analytical database in the cloud, the goal is not to have to manage the database. Now they have different levels of where that goes to us, how much you have to manage or what you have to manage, but ultimately they all manage the basic administrative or the pedantic tasks that DBAs have to do, the patching, the tuning, the upgrading, all that is done by the service provider. So that's the number one thing they all aim at. From that point on, every database has different capabilities and some will automate a whole bunch more than others and will have different primary focuses. So it comes down to what you're looking for or what you need. And ultimately what I've learned from end users is what they think they need upfront is not what they end up needing as they implement. David, anything you'd add to that based on your reading of the Gartner work? Yes, it's a thorough piece of work. It's taking on a huge number of different types of users and size of companies. And I think those are two parameters which really change how companies would look at it. If you're a Fortune 500 or Fortune 2000 type company, you're going to need a broader range of features and you will need to deal with size and complexity in a much greater sense and probably higher levels of availability and reliability and recoverability. Again, on the workload side, there are different types of workload and there is as well as having the two transactional and analytic workloads, I think there's an emerging type of workload which is going to be very important for future applications where you want to combine transactional with analytic in real time in order to automate business processes at a higher level to make the business processes synchronous as opposed to asynchronous. And that degree of granularity, I think is missed in a broader view of the companies and what they offer. It's, in my view, trying in some ways to not compare like with like from a customer point of view. All right, so very nuanced what you're talking about. Let's get into it. Maybe that'll become clear to the audience. So like I said, these are very detailed research notes. There were several, I'll say, analysts cooks in the kitchen, including Henry Cook, who I don't know, but four other contributing analysts, two of whom are Cuban alum, Don Feinberg and Merv Adrian, both really awesome researchers and Rick Greenwald along with Adam Rontel. And these are public documents. You can go on the web and search for these. So I wonder if we could just look at some of the data and bring up, guys, bring up slide one here. And so we'll first look at the operational side and they broke it into four use cases, the traditional transaction use cases, the augmented transaction processing, a stream event processing and operational intelligence. And so we're going to show you a lot of data here. So what Gardner did is they essentially evaluated critical capabilities or think of features and functions and gave them a waiting and then a rating. So it was a waiting and rating methodology. The rating was on a scale of one to five and they waited the importance of features based on their assessment and talking to the many customers they talked to. So you can see here in the first chart, we're showing both the traditional transactions and the augmented transactions. And the first thing that jumps out at you guys is that Oracle with Autonomous is off the charts, far ahead of anybody else on this. And actually guys, if you just bring up slide number two, we'll take a look at the stream event processing and operational intelligent use cases. And you can see again, Oracle has a big lead. And I don't want to necessarily go through every vendor here, but guys, if you don't mind going back to the first slide, because I think this is really the core of transaction processing. So let's look at this. You got Oracle, you got SAP HANA right there. Interestingly, Amazon Web Services with Aurora, you got IBM DB2, which goes back to the good old days down the list. But so let me again, start with Mark. So why is, I mean, I guess this is no surprise, Oracle sort of owns the mission critical for the database space they earned that years ago, one that over the likes of DB2 and Informix and Sidebase and they emerged as number one there. But what do you make of this data, Mark? If you look at this data in a vacuum, you're looking at specific functionality. I think you need to look at all the slides in total. And the reason I bring that up is because I agree with what David said earlier, in that the use case that's becoming more prevalent is the integration of transaction and analytics. And more importantly, it's not just your traditional data warehouse, but it's AI analytics. It's big data analytics. It's users are finding that they need more than just simple reporting. They need more in depth analytics so that they can get more actionable insights into their data where they can react in real time. And so if you look at it just as a transaction, that's great. If you look at it just as a data warehouse, that's great or analytics, that's fine. If you have a very narrow use case, yes. But I think today what we're looking at is it's not so narrow. It's sort of like if you bought a streaming device and it only streamed Netflix and then you need to get another streaming device because you want to watch Amazon Prime, you're not going to do that. You want one that does all of it. And that's kind of what's missing from this data. So I agree that the data is good, but I don't think it's looking at it in a total encompassing manner. Well, so before we get off the horses on the track because I love to do that. I just kind of let's talk about that. So Mark, you're putting forth, you seem to agree on that premise that the database that can do more than just one thing is of appeal to customers. Suppose that makes, certainly makes sense from a cost standpoint, but guys, feel free to flip back and forth between slides one and two, but you can see SAP HANA, I'm not sure what cloud that's running on is probably running in a combination of clouds, but scoring very strongly. I thought Aurora, given AWS says one of the fastest growing services in history and they've got it ahead of DB2 just on functionality, which is pretty impressive. I love Google Spanner, love what they're trying to accomplish there. You know, you go down to Microsoft, it's kind of the always good enough database and that's how they succeed and et cetera, et cetera. But David, sounds like you agree with Mark. I would say, I would think though, Amazon kind of doesn't agree because they're like a horses for courses. So I wonder if you could comment on that. Well, I want to comment on two vectors. The first vector is that the size of customer mid-sized customer versus a global 2000 or global 500 customer. For the smaller customer, that's the heart of AWS and they are taking their applications and putting pretty well everything into their cloud, the one cloud. And Aurora is a good choice. But when you start to get to a requirements as you do in larger companies of very high levels of availability, the functionality is not there. You're not comparing apples with apples is two very different things. So from a tier one functionality point of view, IBM, DB2 and Oracle have far greater capability for recovery and all the features that they've built in over here. You mean because of the maturity? Because of their focus on transaction and recovery, et cetera. So SAP though, Hannah, I mean, that's, and then I wanted your comments on that, either of you or both of you. I mean, SAP I think has a stated goal of basically getting its customers off Oracle. That's, you know, there's always this urinary between the two companies by 2024. Larry has said that ain't going to happen. You know, Amazon, we know still runs on Oracle. It's very hard to migrate mission critical. David, you and I know this well, Mark, you as well. So, you know, people often say, well, everybody wants to get off Oracle, too expensive, blah, blah, blah. But, you know, we talk to a lot of Oracle customers. They're very happy with the reliability, availability, recoverability, feature set. I mean, the core of Oracle seems pretty stable. But I wonder if you guys could comment on that. Maybe, Mark, you go first. Sure. I've recently done some in-depth comparisons of Oracle and Aurora and all their other RDS services and Snowflake and Google and a variety of them. And ultimately what surprised me is, you made a statement, it costs too much. It actually comes in half of Aurora for the most cases. And it comes in less than half of Snowflake in most cases, which surprised me. But no matter how you configure it, ultimately based on a couple of things, each vendor is focused on different aspects of what they do. Let's say Snowflake, for example, they're on the analytical side. They don't do any transaction processing, but- Yeah, so if I can, sorry to interrupt. Guys, if you could bring up the next slide, that would be great. So that would be slide three, because now we get into the analytical piece, Mark, which you're talking about, that's what Snowflake specialty is. So please carry on. Yeah, and what they're focused on is sharing data among customers. So if, for example, you're an automobile manufacturer and you've got a huge supply chain, you can share the data without copying the data with any of your suppliers that are on Snowflake. Now, can you do that with the other data warehouses? Yes, you can. But the focal point is for Snowflake, that's where they're aiming at. And whereas, let's say the focal point for Oracle is gonna be performance. So their performance affects costs because the higher the performance, the less you're paying for the performing part of the pipe payment scale, because you're paying per second for the CPUs that you're using. Same thing on Snowflake, but the performance is higher, therefore you use less. I mean, there's a whole bunch of things to come into this, but at the end of the day, what I found is Oracle tends to be a lot less expensive than the prevailing wisdom. So let's talk value for a second, because you said something that, yeah, the other databases can do what Snowflake's doing. My understanding of what Snowflake is doing is they built this global data mesh across multiple clouds. So not only are they compatible with Google or AWS or Azure, but essentially you sign up for Snowflake and then you can share data with anybody else in the Snowflake cloud. That I think is unique. And I know a Redshift, for instance, just announced Redshift data sharing. And I believe it's just within clusters, within a customer as opposed to across an ecosystem. And I think that's where the network effect is pretty compelling for Snowflake. So independent of costs, you can debate about costs and the lack of transparency of, because AWS, you don't know what the bill is going to be at the end of the month. And that's the same thing with Snowflake. But I find that, and by the way guys, you can flip through slides three and four because we've got, let me just take a quick break here here, data warehouse, logical data warehouse. And then the next slide four, you got data science, deep learning and operational intelligent use cases. And you can see, Teradata came out in the mid 1980s and dominated in that space. Oracle does very well there. You can see Snowflake pop up SAP with the data warehouse, Amazon with Redshift, Google with BigQuery gets a lot of high marks from people, cloud errors in there. So you see some of those names, but so Mark and David, to me, that's a different strategy. They're not trying to be just a better data warehouse, easier data warehouse. They're trying to create Snowflake that is an incremental opportunity as opposed to necessarily going after, for example, Oracle, David, your thoughts. Yeah, I absolutely agree. I mean, ease of use is a primary benefit for Snowflake. It enables you to do stuff very easily. It enables you to take data without ETL, without any of the complexity. It enables you to share a number of resources across many different users and be able to bring in what that particular user wants or part of the company wants. So in terms of where they're focusing, they've got tremendous ease of use, tremendous focus on what the customer wants. And you pointed out yourself, the restrictions there are of doing that both within Oracle and AWS. So yes, they have really focused very, very hard on that. Again, for the future, they are bringing in a lot of additional functions. They're bringing in Python into it, not Python, JSON into the database. They can extend the database itself. Whether they go the whole hog and put in transaction as well, that's probably something they're maybe thinking about, but not at the moment. Well, but they obviously have to have cam expansion designs because Mark, I mean, if they just get 100% of the data warehouse market, they're probably at a third of their stock market valuation. So they had better have a roadmap and plans to extend there. But I want to come back Mark to this notion of the right tool for the right job or best of breed for a specific horse for course versus this kind of notion of all in one. I mean, at two different ends of the spectrum, you're seeing Oracle obviously very successful based on these ratings and based on their track record and Amazon, I think a lost count of the number of data stores with Redshift and Aurora and Dynamo on and on and on. So they clearly want to have that primitive, different APIs for each access. Completely different philosophies is like Democrats and Republicans. Mark, your thoughts as to who ultimately wins in the marketplace. Well, it's hard to say who's ultimately going to win, but if I look at Amazon, Amazon is an all-card type of system. If you need time series, you go with their time series database. If you need a data warehouse, you go with Redshift. If you need transaction, you go with one of the RDS databases. If you need JSON, you go with a different database. Everything is a different unique database. Moving data between these databases is far from simple. If you need to do analytics on one database from another, you're going to use other services that cost money. So yeah, each one will do what they say it's going to do, but it's going to end up costing you a lot of money when you do any kind of integration. And you're going to add complexity and you're going to have errors. There's all sorts of issues there. So if you need more than one, probably not your best route to go. But if you need just one, it's fine. And on Snowflake, you raise the issue that they're going to have to add transactions. They're going to have to rewrite the database. They have no indexes whatsoever in Snowflake. I mean, part of the simplicity that David talked about is because they had to cut corners, which makes sense. If you're focused on a data warehouse, you cut out the indexes. Great, you don't need them. But if you're going to do transactions, you kind of need them. So you're going to have to do some more work there. Well, so I don't know. I have a different take on that, guys. I'm not sure if Snowflake will add transactions. I think maybe their hope is that the market that they're creating is big enough. I mean, I have a different view of this in that I think the data architecture is going to change over the next 10 years, as opposed to having a monolithic system where everything goes through that big data platform, the data warehouse of the data lake. I actually see what Snowflake is trying to do. And I'm sure others will join them is to put data in the hands of product builders, data product builders, or data service builders. I think they're betting that that market is incremental and maybe they don't try to take on. I think it would maybe be a mistake to try to take on Oracle. And Oracle's just too strong. I wonder, David, if you could comment. So it's interesting to see how strong Gartner rated Oracle in cloud database, because you don't, I mean, okay, Oracle's got OCI, but you think of cloud, you think Google or Amazon, Microsoft and Google. But if I have a transaction database running on Oracle, very risky to move that, right? And so we've seen that. Interesting, Amazon's a big customer of Oracle. Salesforce is a big customer of Oracle. Larry's very outspoken about those companies. SAP customers are many most are using Oracle. I don't, you know, it's not likely that they're going anywhere. My question to you, David, is first of all, why do they want to go to the cloud? And if they do go to the cloud, is it logical that the least risky approach is to stay with Oracle, if you're an Oracle customer or DB2, if you're an IBM customer and then move those other workloads that can move, whether it's more data warehouse oriented or incremental transaction work that could be done in Aurora. I think the first point, why should Oracle go to the cloud? Why has it gone to the cloud? And there is- More so, more so, why would customers of Oracle- Why would customers want to- That's really my question. Well, Oracle have got Oracle clouded customer. And that is a very powerful way of doing it where exactly the same Oracle system is running on-premise or in the cloud. You can have it where you want. You can have them joined together. That's unique. That's unique in the marketplace. So that gives them a very special place in large customers that have data in many different places. The second point is that moving data is very expensive. Mark was making that point earlier on. Moving data from one place to another place between two different databases is a very expensive architecture. Having the data in one place where you don't have to move it, where you can go directly to it gives you enormous capabilities for a single database type. And I'm sure that from an analytic point of view, that's where Snowflake is going to a large single database. But where Oracle is going to is where you combine both the transactional and the other one. And as you say, the cost of migration of databases is incredibly high, especially transaction databases, especially large complex transaction databases. And it takes a long time, at least a two year, and it took five years for Amazon to actually succeed in getting a lot of their stuff over. And five years, they could have been doing an awful lot more with the people that they used to bring it over. So it was a marketing decision as opposed to a rational business decision. It's the holy grail of the vendors. They all want your data in their database. So I Amazon put so much effort into it. Oracle's got obviously a very strong position. It's got growth and it's new stuff. It's old stuff. The problem with Oracle has, like many of the legacy vendors, it's the size of the install base is so large and it's shrinking. And the new stuff is legacy stuff is shrinking. The new stuff has grown very, very fast, but it's not large enough yet to offset that. You see that in Oracle learnings. So very positive news on the cloud database and they just got to work through that transition. Let's bring up slide number five because Mark, this is to me the most interesting. So we've just shown all these detailed analyses from Gartner. And then you look at the magic quadrant for cloud databases. And despite Amazon being behind Oracle or Teradata or whomever in every one of these ratings, they're up to the right. Now of course Gartner will caveat this and say it doesn't necessarily mean you're the best but of course everybody wants to be in the upper right. We all know that, but it doesn't necessarily mean that you should go buy that database. I agree with what Gartner's saying, but look at Amazon, Microsoft and Google are like one, two and three. And then of course you've got Oracle up there and then the others. So I found that very curious. It's like there was a dissonance between the hardcore ratings and then the positions in the magic quadrant. Why do you think that is Mark? It didn't surprise me in the least because of the way that Gartner does its magic quadrants. The higher up you go in the vertical is very much tied to the amount of revenue you get in that specific category in which they're doing the magic quadrant. Doesn't have to do with any of the revenue from anywhere else. Just that specific quadrant is with that specific type of market. So when I look at it, Oracle's revenue, still a big chunk of the revenue comes from on-prem, not in the cloud. So you're looking just at the cloud revenue. Now on the right side, moving to the right of the quadrant, that's based on functionality, capabilities, the resilience, other things other than revenue. So visionary says, hey, how far are you on the visionary side? Now how they wait that again comes down to Gartner's experts and how they want to wait it and what makes more sense to them. But from my point of view, the right side is as important as the vertical side because the vertical side doesn't measure the growth rate either. And if we look at these, some of these are growing much faster than the others. For example, Snowflake's growing incredibly fast. And that doesn't reflect in these numbers from my perspective. Oracle's growing incredibly fast in the cloud. As David pointed out earlier, it's not just in their cloud where they're growing, but it's cloud of customer, which is basically an extension of their cloud. I don't know if that's including these numbers or not in the revenue side. So there's a number of factors. Could it be in your opinion, Mark, would you include that in your definition of cloud? The things that are hybrid and on-prem with that cloud experience? Yes, well, especially, well, again, it depends on the hybrid. For example, if you have your own license in your own hardware, but it connects to the cloud, no, I wouldn't include that. If you have a subscription license and subscription hardware that you don't own, but it's owned by the cloud provider, but it connects with the cloud as well, that I would. Interesting. Well, to your point about growth, you're right. I mean, it's probably looking at revenues, looking backwards from guys like Snowflake, it will be double the next one of these. It's also interesting to me on the horizontal axis to see cloud air and Databricks further to the right than Snowflake, because that's kind of the data lake crowd. It is. And then, of course, you've got all the other, I mean, database used to be boring. It's so, you know, such a hot market space here. David, your final thoughts on all this stuff. What is the customer takeaway here? What should I, what should by cloud database management strategy be? Well, I was positive about Oracle. Let's take some of the negatives of Oracle. First of all, they don't make it very easy to run on other platforms. So they have put in terms and conditions which make it very difficult to run on AWS, for example, you get double counts on the licenses, et cetera. So they haven't played well. It wasn't negotiable, by the way. Those are, you're big enough. Yeah, they can be, yes. If you're big enough, they're negotiable. But Oracle certainly hasn't made it easy to work with other plate, other clouds. What they did very... How about Microsoft? Well, no, no. So exactly what I was going to say. Oracle with adjacent workloads have been working very well with Microsoft. And you can then use Microsoft Azure and use a database adjacent in the same data center working with integrated very nicely indeed. And I think Oracle has got to do that with AWS. It's got to do that with Google as well. It's got to provide a service for people to run where they want to run things, not just on the Oracle Cloud. If they did that, that would, in my term, in my opinion, be a very strong move and would make their capabilities available in many more places. Great. Awesome. Hey, Mark, thanks so much for coming to theCUBE. Thank you, David, as well. And thanks to Gartner for doing all this great research and making it public on the web. You can, if you just search critical capabilities for cloud database management systems for operational use cases, that's a mouthful. And then do the same for analytical use cases and the magic quadrant is the third doc for cloud database management systems. You'll get about two hours of reading. And I learned a lot. And I learned a lot here too. I appreciate the context, guys. Thanks so much. My pleasure. All right. And thank you for watching everybody. This is Dave Vellante for theCUBE. We'll see you next time.