 Oracle continues to enhance MySQL Heatwave at a very rapid pace. The company is now in its fourth major release since the original announcement in December, 2020. One of the main criticisms of MySQL Heatwave is that it only runs on OCI, Oracle Cloud Infrastructure, and is a lock-in to Oracle's cloud. Oracle recently announced that Heatwave is now going to be available on AWS's cloud and it announced its intent to bring MySQL Heatwave to Azure. So MySQL Heatwave on AWS is a significant TAM expansion move for Oracle because of the momentum AWS Cloud continues to show. And evidently, the Heatwave engineering team has taken the development effort from OCI and is bringing that to AWS with a number of enhancements that we're going to dig into. Today, Nipin Agawal, Senior Vice President of MySQL Heatwave at Oracle, is back with me on a CUBE conversation to discuss the latest Heatwave news. And we're eager to hear any benchmarks relative to AWS or any others. Nipon has been leading the Heatwave engineering team for over 10 years and has over 185 patents in database technology. Welcome back to the show, Nipin, good to see you. Thank you, Dave, very happy to be back. Now, for those who might not have kept up with the news to kick things off, give us an overview of MySQL Heatwave and its evolution so far. Sure. So MySQL Heatwave is a fully managed MySQL database service offering from Oracle. Traditionally, MySQL has been designed and optimized for transaction processing. So customers of MySQL, when they had to run analytics or when they had to run machine learning, they would extract the data out of MySQL into some other database for doing analytic processing or machine learning processing. MySQL Heatwave provides all these capabilities built into a single database service, which is MySQL Heatwave. So customers of MySQL don't need to move the data out with the same database. They can run transaction processing analytics, mixed workloads, machine learning, all with a very, very good performance and very good price performance. Furthermore, one of the design points of Heatwave is a scale out architecture. So the system continues to scale and perform very well. Even when customers have very large data sizes. So we've seen some interesting moves by Oracle lately, the collaboration with Azure, we've covered that pretty extensively. What was the impetus here for bringing MySQL Heatwave onto the AWS cloud? What were the drivers that you considered? Right. So Dave, one of the observations is that a very large person page of users of MySQL Heatwave are AWS users who are migrating of Aurora or Edge. So already we see that a good percentage of MySQL Heatwave customers are migrating from AWS. However, there are some AWS customers who are still not able to migrate to MySQL Heatwave. And the reason is because of exorbitant egress costs which AWS charges. So in order to migrate a workload from AWS to OCI, AWS charges a very high egress fees which becomes prohibited for the customer. Or the second example we have seen is that the latency of accessing a database which is outside of AWS is very high. So there's a class of customers who would like to get the benefits of MySQL Heatwave but were unable to do so. And with this support of MySQL Heatwave inside of AWS, these customers can now get all the goodies of in the benefits of MySQL Heatwave without having to pay the high egress fees or without having to suffer with the poor latency which is because of the AWS architecture. Okay, so you're basically meeting the customers where they are. So was this a straightforward like lifted shift from Oracle Cloud infrastructure to AWS? No, it is not because one of the design goals we have with MySQL Heatwave is that we want to provide our customers with the best price performance regardless of the cloud. So when we decided to offer MySQL Heatwave on AWS, we have optimized MySQL Heatwave on AWS. So one of the things to point out is that this is a service where the data plane, control plane and the console are natively running on AWS. And the benefit of doing so is that now we can optimize MySQL Heatwave for the AWS architecture. In addition to that, we've also announced bunch of new capabilities as a part of the service which will also be available to the MySQL Heatwave customers on OCI but we just announced them and we are offering them as a part of MySQL Heatwave offering on AWS. So I just want to make sure I understand this. It's not like you just wrapped your stack in a container and stuck it into AWS to be hosted. You're saying you're actually taking advantage of the capabilities of the AWS cloud natively. And I think you've made some other enhancements as well that you're alluding to. Can you maybe elucidate on those? Sure, so for starters, we have taken the MySQL Heatwave code and we have optimized it for the AWS infrastructure with its compute network and such. As a result, customers get very good performance and price performance with MySQL Heatwave in AWS. That's one, right? Performance. Second thing is we have designed a new interactive console for the service which means that customers can now provision their instances with the console. But in addition, they can also manage their schemas. They can run queries directly from the console. Autopilot is integrated with the console. We have introduced performance monitoring. So a lot of capabilities which we have introduced as a part of the new console. The third thing is that we have added a bunch of new security features. We have exposed some of the security features which were a part of the MySQL Enterprise Edition as a part of the service, which gives customers now a choice of using these features to build more secure applications. And finally, we have extended MySQL Autopilot for a number of OLTP use cases. In the past, MySQL Autopilot had a lot of capabilities for analytics. And now we have augmented MySQL Autopilot to offer capabilities for OLTP workloads as well. But there was something in your press release called auto thread pooling. So it provides higher and sustained throughput at high concerns, concurrency by determining the optimal number of transactions which should be executed. What is that all about the auto thread pool? It seems pretty interesting. How does it affect performance? Can you help us understand that? Yes, and this is one of the capabilities I was leading to which we have added in MySQL Autopilot for transaction processing. So here's the basic idea. If you have a system where there's a large number of OLTP transactions coming in at a high degrees of concurrency in many of the existing systems or MySQL based systems, it can lead to a state where there are a few transactions executing but a bunch of them can get blocked. With Autopilot thread pooling, what we basically do is we do workload-aware admission control. And what this does is it figures out that what's the right scheduling for all of these algorithms so that either the transactions are executing or as soon as something frees up, they can start executing. So there's no transaction which is blocked. The advantage to the customer of this capability is two-fold. A, you get significantly better throughput compared to servers like Aurora at high levels of concurrency. So at high concurrency, for instance, MySQL heat wave because of this capability, the Autopilot thread pooling offers up to 10 times higher throughput compared to Aurora. That's the one first benefit, better throughput. The second advantage is that the throughput of the system never drops even at high levels of concurrency. Whereas in the case of Aurora, the throughput goes up, but then at high concurrencies, let's say starting say level of 500 or something depends upon the underlying ship you're using, the throughput starts dropping. Whereas with MySQL heat wave, the throughput never drops. Now, the ramification for the customer is that if the throughput is not gonna drop, the user can start off with a small shape, get the performance and be assured that even if their workload increases, they will never get a performance which is worse than what they're getting with lower levels of concurrency. This leads to customers provisioning a shape which is just right for them and if they need they can go with the larger shape. They don't like overpay. So those are the two benefits, better performance and sustained throughput regardless of the level of concurrency. So how do we quantify that? I know you've got some benchmarks. How can you share comparisons with other cloud databases especially interested in Amazon's own databases? They're obviously very popular and are you publishing those again on GitHub as you have done in the past? Take us through the benchmarks. Sure, so benchmarks are important because that gives customers a sense of what performance to expect and what price performance to expect. So we have run a number of benchmarks and yes, all these benchmarks are available on GitHub for customers to take a look at. So we have performance results on all the three cluster workloads, OLTP, analytics and machine learning. So let's start with OLTP. For OLTP and primarily because of the auto thread pooling feature, we show that for TTCC for a 10 gig dataset at high levels of concurrency, heat wave offers up to 10 times better throughput and this performance is sustained. Whereas in the case of Aurora, the performance really drops. So that's the first thing that 10 gigabyte TTCC, high concurrency, the performance for the throughput for heat wave is 10 times better than Aurora. For analytics, we have done a comparison of MySQL heat wave in AWS and compared with Redshift, Snowflake, Google BigQuery. We find that the price performance of MySQL heat wave compared to Redshift is seven times better. So MySQL heat wave in AWS provides seven times better price performance than Redshift. That's a very interesting result to us, which means that customers of Redshift are really going to take the server seriously because they're going to get seven times better price performance and this is all running in AWS. So compared. Oh, go ahead please, carry on. Yeah, and then I was going to say compared to like Snowflake heat wave in AWS offers 10 times better price performance and compared to Google BigQuery, it offers 12 times better price performance. And this is based on a four terabyte TTCH workload results are available on GitHub. And then the third category is machine learning and for machine learning, for training, the performance of MySQL heat wave is 25 times faster compared to that chip. So all the three workloads, we have benchmarks and results and all of these scripts are available on GitHub. Okay, so you're comparing MySQL heat wave on AWS to Redshift and Snowflake on AWS and you're comparing MySQL heat wave on AWS to BigQuery, obviously running on Google. One of the things Oracle's done in the past when you get to price performance and I've always tried to call fouls, you're like double your price for running the Oracle database, not heat wave, but Oracle database on AWS and then you'll show how it's so much cheaper on Oracle, we'll be like, okay, come on, but they're not doing that here. You're basically taking MySQL heat wave on AWS, I presume you're using the same pricing for whatever, EC2, whatever else you're using storage, reserved instances, that's apples to apples on AWS and you have to obviously do some kind of mapping for Google for BigQuery. Can you just verify that for me? Right, we have been more than fair on two dimensions. The first thing is when I'm talking about the price performance for say analytics for with MySQL heat wave, the cost I'm talking about for MySQL heat wave is the cost of running transactional processing, analytics and machine learning. So it's a fully loaded cost for the case of MySQL heat wave. Whereas when I'm talking about Redshift or when I'm talking about Snowflake, I'm just talking about the cost of these databases for running analytics only. So it's not including the source database which may be Aurora or some other database. So that's the first aspect that for a heat wave, it's the cost for running all three kinds of workloads. Whereas for the competition, it's only for running analytics. The second thing is that for these other services whether it's Redshift or Snowflake or such, you're talking about one year fully paid upfront cost. So that's what most of the customers would pay or many of the customers would pay that they will sign a one year contract and pay all the costs ahead of time because they get a discount. So we are using that price in the case of Snowflake, the cost we are using is the standard edition price, not the enterprise edition price. So yes, we have been more than clear in this comparison. Yeah, I think that's an important point. I saw an analysis by Mark Stamer on Wikibon where he was doing the TCO comparisons. And I mean, if you have to use two separate databases and two separate licenses and you have to do ETLing and all the labor associated with that, that's a big deal. You're not even including that aspect in your comparison. So that's pretty impressive. To what do you attribute that, given that unlike OCI, within the AWS cloud, you don't have as much control over the underlying hardware. Right, so look, hardware is one aspect. Okay, so there are three things which give us disadvantage. The first thing is we have designed a heat wave for a scale out architecture. So we came up with new algorithms. We have come up with one of the design points for heat wave is a massively partitioned architecture which leads to a very high degree of patterns. So that's a lot of IP which we have built. So that's the first part. The second thing is that although we don't have control over the hardware, but the second design point for heat wave is that it is optimized for commodity cloud and the commodity infrastructure. So we kind of analyze what to say the compute we get, how much of network bandwidth do we get, how much of like say, objects to a bandwidth we get in AWS and we have tuned heat wave for that. That's the second point. And the third thing is MySQL autopilot which provides machine learning based automation. So what it does is that as the user's workload is running it learns from it, it improves like the various parameters in the system. So the system keeps getting better as you run more and more queries. And this is the third thing as a result of which we get a significant edge over the competition. Interesting. I mean, look, any ISV can go on any cloud and take advantage of it and that's, I love it, we live in a new world here. How about machine learning workloads? What did you see there in terms of performance and benchmarks? Right. So machine learning, we offer three capabilities. Training, which is fully automated, running inference and explanations. So one of the things which many of our customers told us coming from the enterprise is that explanations are very important to them because customers wanna know that why did the system choose a certain prediction? So we offer explanations for all models which have been generated by Heat Fibonet. That's the first thing. Now, one of the interesting things about training is that training is usually the most expensive phase of machine learning. So we have spent a lot of time improving the performance of training. So we have a bunch of techniques which we have developed inside of Oracle to improve the training process. For instance, we have a meta-learn proxy models which really give us an advantage. We use adaptive sampling. We have invented new techniques for parallelizing the hyperparameter sets. So as a result of a lot of this work, our training is about 25 times faster than that shift ML. And all the data is inside the database. All this processing is being done inside the database. So it's much faster. It is inside the database. And I want to point out that there is no additional charge for the Heat Fib customers because we're using the same cluster, you're not invoking any of the service. So all of these machine learning capabilities are being offered at no additional charge inside the database, and at a performance which is significantly faster than the shift ML. Are you taking advantage of, or is there any need, not need, but any advantage that you can get by exploiting things like Graviton? We've talked about that a little bit in the past, or Tranium, you mentioned training. So custom silicon that AWS is doing. Are you taking advantage of that? Do you need to? Can you maybe give us some insight there? Sure, so there are two things, right? We are always evaluating what are the choices we have from a hardware perspective in ways that are opportunity for us to leverage, right? And like all the things you mentioned about like say Graviton, we have considered them. But there are two things to consider. One is heat wave is a in-memory system, right? So a heat wave is a dominant cost. The processor is a percent of the cost, but memory is a dominant cost. So what we have evaluated and found is that the current shape which we are using is going to provide our customers with the best price performance. That's the first thing. The second thing is that there are opportunities at times when we can use a specialized processor for accelerating the workload a bit, but then it becomes a matter of the cost to the customer. The advantage of our current architectures on the same hardware, customers are getting very good OTP performance, very good analytic performance, and very good machine learning performance. If we were to go with the specialized processor, it may actually, it's a machine learning, but then it's an additional cost with the customers we need to pay. So we are very sensitive to the customer's request which is usually to provide very good performance at a very low cost. And we feel that the current design we have is providing customers very good performance and very good price performance. Yeah, so part of that is architectural, the memory-intensive nature of Heatwave. The other is AWS pricing. If AWS pricing were to flip, it might make more sense for you to take advantage of something like Tranium. Okay, great, thank you. I want to come back to the benchmarks. Because benchmarks are sometimes there, they're artificial, right? Like a car can go from zero to 60 in two seconds, but I might not be able to experience that level of performance. Do you have any real world numbers from customers that have used MySQL Heatwave on AWS and how they look at performance? Yes, absolutely. So the MySQL Heatwave service on AWS, this has been in beta for like since November, right? So we have a lot of customers who have tried the service and what actually we have found is that many of these customers are planning to migrate from Aurora to MySQL Heatwave. And what they find is that the performance difference is actually much more pronounced than what I was talking about. Because with Aurora, the performance is actually much poorer compared to like what I talked about. So in some of these cases, the customers found an improvement from 60 times to 140 times, right? So Heatwave was up to 140 times faster. It was much less expensive. And the third thing, which is noteworthy is that customers need to change their application. So if you ask the top three reasons why customers are migrating, it's because of this. No change to the application much faster and it is cheaper, right? So in some cases like, say Johnny Bytes, what they found is that the performance of their application for the complex queries was about 60 to 90 times faster. Then we had 6D technologies. What they found is that the performance of Heatwave compared to Aurora was 139 times faster. So yes, we do have many such examples from real workloads from customers who have tried it. And all across what we find is Heatwave offers better performance, lower cost, and a single database such that it is compatible with all existing MySQL based applications and workloads. Really impressive. I mean, the analysts I talked to, they're all gaga over Heatwave and I can see why. Okay, last question, maybe two in one. What's next in terms of new capabilities that customers are going to be able to leverage? And any other clouds that you're thinking about? We talked about that up front. Right, so in terms of the capabilities you have seen, like they have been, you know, nonstop attending to the feedback from the customers and reacting to it. And also we have been innovating like organically. So that's something which is going to continue. So yes, you can fully expect that people not rest and continue to innovate. And with respect to the other clouds, yes, we are planning to support MySQL Heatwave on Azure. And this is something which will be announced in the near future. Great. All right, thank you, Nipin. Really appreciate the overview. Congratulations on the work. Really exciting news that you're moving MySQL Heatwave into other clouds. It's something that we've been expecting for some time. So it's great to see you guys making that move. And as always, Nipin, great to have you on theCUBE. Thank you for the opportunity, Dave. All right, and thank you for watching this special CUBE conversation. I'm Dave Vellante and we'll see you next time.