Screaming in the Cloud - Replay - HeatWave and the Latest Evolution of MySQL with Nipun Agarwal

Starting point is 00:00:00 Data plane, control plane, console, they are all running natively in AWS. And this provides for a very seamless integration or seamless experience for the AWS customers. Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is sponsored by our friends at Oracle and back for a borderline historic third round going out and telling stories about these things. We have Nipun Agarwal, who is, as opposed to his first appearance on the show, has been promoted to senior vice president of MySQL Heatwave. Nipun, thank you for coming back.

Starting point is 00:00:42 Most people are not enamored enough with me to subject themselves to my slings and arrows a second time, let alone a third. So first, thanks. And are you okay over there? Thank you, Corey. Yeah, very happy to be back. This episode is sponsored in part by my day job, the Duck Bill Group. Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles a phone number,

Starting point is 00:01:15 but nobody seems to quite know why that is. To learn more, visit duckbillgroup.com. Remember, you can't duck the duck bill bill. And my CEO informs me that is absolutely not our slogan. So since the last time we've spoken, there have been some interesting developments that have happened. It was pre-announced by Larry Ellison on a keynote stage or an earnings call, I don't recall the exact format, that HeatWave was going to be coming to AWS. Now you've conducted a formal announcement,

Starting point is 00:01:50 this usual media press blitz, et cetera, talking about it with an eye toward general availability later this year, if I'm not mistaken. And things seem to be, if you'll forgive the term, heating up a bit. That is correct. So as you know, we have had MySQL HeatWave on OCI for just about two years now. Very good reception. A lot of people who are using MySQL HeatWave are migrating from other clouds, specifically from AWS. And now we have announced the availability of MySQL HeatWave on AWS. So for those who have not done the requisite homework of listening to the entire back catalog of nearly 400 episodes of this show, what exactly is MySQL HeatWave? Just so we make sure that we set the stage for what we're going to be talking about. Because I sort of get the sense that without a baseline working knowledge of what that is, none of the rest of this is going to make a whole lot of sense. MySQL HeatWave is a managed MySQL service provided by Oracle, but it is different from

Starting point is 00:02:49 other MySQL-based services in the sense that we have significantly enhanced this service such that it can very efficiently process transactions, analytics, and in-database machine learning. So what customers get with this service, with MySQL HeatWave, is a single MySQL database which can process OLTP, which is transaction processing, real-time analytics, and machine learning.

Starting point is 00:03:14 And they can do this without having to move the data out of MySQL into some other specialized database services for running analytics or machine learning. And all existing tools and applications which work with MySQL work as is, because this is something you have in as a server. In addition to that, it provides very good performance and very good price performance

Starting point is 00:03:35 compared to other similar services out there. The idea historically that some folks were pushing around the idea of multi-cloud was that you would have workloads that, well, they live in one cloud, but the database was going to be all the way across the other side of the internet, living in a different provider. And in practice, what we generally tend to see is that where the data lives is where the compute winds up living. By and large, it's easier to bring the compute resources to the data than it is to move the data to the compute. Just because data egress in most of the cloud providers, notably exempting yours, is astronomically expensive. You are, if I recall correctly, less than 10% of AWS's data egress charge on just retail pricing alone, which is wild to me. So first, thank you for keeping that up

Starting point is 00:04:25 and not raising prices, because I would have felt rather annoyed if I'd been saying such good things and it was, ha ha, it was a bait and switch. It was not, I'm still a big fan. So thank you for that first and foremost. Certainly, and what he described is absolutely correct, that while we have a lot of customers migrating from AWS

Starting point is 00:04:42 to use MySQL HeatWave and OCI, a class of customers are unable to. And the number one reason they're unable to is that AWS charges these customers a very high egress fees to move the data out of AWS into OCI for them to benefit from MySQL HeatWave. And this has definitely been one of the key incentives for us, the key motivation for us to offer MySQL HeatWave on AWS so that customers don't need to pay this exorbitant data egress fees. I think it's fair to disclose that I periodically advise a variety of different cloud companies from a perspective of voice of the customer feedback, which essentially distills down to me asking really annoying slash obnoxious questions

Starting point is 00:05:28 that I, as a customer, legitimately want to know, but people always frown at me when I ask that in vendor pitches. For some reason, when I'm doing this on an advisory basis, people instead nod thoughtfully and take notes. So, you know, it at least feels better from my perspective. Oracle Cloud has been one of those. And I've been kicking the tires on the AWS offering that you folks have built out for a bit

Starting point is 00:05:50 of time now. I have to say this, it is legitimate. I was able to run a significant series of tests on this. And what I found going through that process was interesting on a bunch of different levels. I'm wondering if it's okay with you, if we go through a few of them, just things that jumped out to me as we went through a series of conversations around, so we're going to run a service on AWS. And my initial answer was, is this Oracle? Are you sure? And to here we are today, where you're talking about it in press releases. Yes, certainly fine with me. Please go ahead. So I think one of the first questions I had when you said, we're going to run a database service on AWS itself was, if I'm true to type, it's going to be fairly sarcastic, which is, oh,

Starting point is 00:06:37 thank God, finally, a way to run a MySQL database on AWS. There's never been one of those before, unless you count EC2 or Aurora or Redshift, depending upon how you squint at it, or a variety of other increasingly strange things. It feels like that has been a largely saturated market in many respects. I generally don't tend to advise on things that I find patently ridiculous. And your answer was great, but I don't want to put words in your mouth. What was it that you saw that made you say, ah, we're going to put a different database offering on AWS? And no, it's not a terrible decision. Got it. Okay. So if you look at it, the value proposition, which MySQL Heatwave offers

Starting point is 00:07:18 is that customers of MySQL or customers of MySQL compatible databases, whether it's Aurora or whether it's RDS MySQL, or even like customers of Redshift, they have been migrating to MySQL HeatWave on OCI for the reasons I said. It's a single database. Customers don't need to have multiple databases for managing different kinds of workloads. It's much faster. It's a lot less expensive. So there are a lot of value propositions.

Starting point is 00:07:45 So what we found is that if you were to offer MySQL HeatWave on AWS, it'll significantly ease the migration of other customers who might be otherwise thinking that it'd be difficult for them to migrate, perhaps because of the high egress cost of AWS, or because of the high latency, some of the applications in the AWS incurred

Starting point is 00:08:05 when the database is running somewhere else. Or if they really have an ecosystem of applications already running on AWS, and they just want to replace the database, it'll be much easier for them if MySQL HeatWave was offered in AWS. Those are the reasons why we feel it's a compelling proposition that if existing customers of

Starting point is 00:08:23 AWS are willing to migrate the cloud from AWS to OCI and use MySQL HeatWave, there's clearly a value proposition we are offering. And if we can now offer the same service in AWS, it'll hopefully increase the number of customers who can benefit from MySQL HeatWave. One of the next questions I had going in was, okay, so what actually is this under the hood? Is this you effectively just stuffing some software into a machine image or an AMI or however they want to mispronounce that word over in AWS land, and then just making it available to your account and running that?

Starting point is 00:08:59 Where's the magic or mystery behind this? It feels like the next more modern cloud approach is to stuff the whole thing into a Docker container. But that's not what you wound up doing. Correct. So HeatWave has been designed and architected for scale-out processing, and it's been optimized for the cloud. So when we decided to offer MySQL HeatWave on AWS,

Starting point is 00:09:20 we have actually gone ahead and optimized our server for the AWS architecture. So the processor we are running on, right? We have optimized our software for that instance types in AWS, right? So the data plane has been optimized for AWS architecture. The second thing is we have a brand new control plane layer. So we have, it's not the case that we're just taking

Starting point is 00:09:41 what we had in OCI and we're running it on AWS. We have optimized the data plane for AWS. We have a native control plane, which is running on AWS, which is using the respective services on AWS. And third, we have a brand new console, which we are offering, which is a very interactive console where customers can run queries from the console. They can do data management from the console. They're able customers can run queries from the console. They can do data management from the console. They're able to use autopilot from the console. And we have performance monitoring from the console, right? So data plane, control plane, console, they're all running natively in AWS.

Starting point is 00:10:24 And this provides for a very seamless integration or seamless experience for the AWS customers. I think it's also a reality, however much we may want to pretend otherwise, that if there is an opportunity to run something in a different cloud provider that is better than where you're currently running it now, by and large, customers aren't going to do it. Because it needs to not just be better but so astronomically better in ways that are foundational to a company's business model in order to justify the tremendous expense of a cloud migration not just in real out-of-pocket cost in dollars and cents that are easy to measure but also in terms of engineering effort in terms of opportunity cost because while you're doing that you're not doing other things instead.

Starting point is 00:11:06 And on some level, people tend to only do that when there's an overwhelming strategic reason to do it. When folks already have existing workloads on AWS, as many of them do, it stands to reason that they are not going to want to completely deviate from that strategy just because something else offers a better database experience on any number of axes. So meeting customers where they are is one of the,

Starting point is 00:11:32 I guess, foundational shifts that we've really seen from the entire IT industry over the last 40 years. Rather than, you will buy it from us and you will tolerate it, it's now customers have choice. And meeting them where they are and being much more, I guess, able to impedance match with them has been critical. And I'm really optimistic about what the launch of this service

Starting point is 00:11:54 pretends for Oracle. Indeed, but let me give you another data point. We find a very large number of Aurora customers migrating to MySQL HeatWave on OCI. And this is the same workload they were running on Aurora, but now they want to run the same workload on MySQL HeatWave on OCI. They're willing to undertake this journey of migration because their applications, they

Starting point is 00:12:18 get much faster and for a lot less price, but they get much faster. Then the second aspect is there's another class of customers who are, for instance, running on Aurora, the transactions workloads, but then they have to keep moving the data. They'll keep performing the ETL process into some other service, whether it's Snowflake or whether it's Redshift for analytics.

Starting point is 00:12:39 Now, with this migration, when they move to MySQL HeatWave, customers don't need to have multiple databases and they get real-time analytics, With this migration when they move to MySQL HeatWave, customers don't need to have multiple databases and they get real-time analytics, meaning that if any data changes inside the server, inside the OLTP database service, if they were to run an analytic query, that query is giving them the latest results.

Starting point is 00:12:58 It's not stale. It is with the ETL process, it gets to be stale. Given that we already found that there were so many customers migrating to OCI to use MySQL HeatWave, I think there's a clear value proposition of MySQL HeatWave. And there's a lot of demand. But as I was mentioning earlier, by having MySQL HeatWave be offered on AWS, it makes the proposition even more compelling. Because as you said, yes, there is some engineering work

Starting point is 00:13:25 that customers may need to do to migrate between clouds. And if they don't want to, then absolutely. Now they have MySQL Heatfave, which they can now use in AWS itself. I think that one of the things I continually find myself careening into, perhaps unexpectedly, is a failure to really internalize just how vast this entire industry

Starting point is 00:13:48 really is. Every time I think I've seen it all, all I have to do is talk to one more cloud customer and I learn something completely new and different. Sometimes it's an innovative, exciting use of a thing. Other times it's people holding something fearfully wrong and trying to use it as a hammer instead and you know if it's dumb and it works is it really dumb there are questions around that and this in turn gave rise to one of my next obnoxious questions as i was looking at what you were building at the time because a lot of your pricing and discussions and framing of this was targeting very large enterprise-style customers. And the price points reflected that. And then I asked the question that Big E Enterprise never quite expects for whatever reason.

Starting point is 00:14:35 It's like, that looks awesome if I have a budget with many commas in it. What can I get for $4? And as of this recording, pricing has not been finalized slash published for the service. But everything that you have shown me so far absolutely makes developing on this for a proof of concept or an evening puttering around completely tenable. It is not bound to a fixed period of licensing. It's use it when you want to use it, turn it off when you're done. And the hourly pricing is not egregious. I think that that is something that historically Oracle database offerings have not really aligned with. OCI very much has, particularly with an eye

Starting point is 00:15:21 toward its extraordinarily awesome free tier that's always free. But this feels like it's a weird blending of the OCI model versus historical Oracle database pricing models in a way that, honestly, I'm pretty excited about. So we react to what the customer requirements and needs are. So for this class of customers who are using, say, RDS, MySQL, or Aurora, we understand that they are very cost-sensitive. So one of the things which we have done in addition to offering MySQL, HeatWave, and AWS is based on the customer feedback and such. We are now offering a small shape of HeatWave instance in addition to the regular large shape. So if customers want to just kick the tires,

Starting point is 00:16:00 if developers just want to get started, they can get a MySQL node with HeatWave for less than 10 cents an hour. So for less than 10 cents an hour, they get the ability to run transaction processing, analytics, and machine learning. And if you were to compare the corresponding cost of Aurora for the same core count, it's 12 and a half cents. And that's just Aurora without Redshift or without SageMaker. So yes, you're right that based on the feedback and we found that it would be much more attractive to have this low-end shape for the AWS developers. We are offering this smaller ship and yeah, it's very, very affordable. It's about just shy of 10 cents an hour.

Starting point is 00:16:41 This brings up another question that I raised pretty early on in the process because you folks kept talking about shapes. And it turns out that is the Oracle Cloud term that applies to instance size over in AWS land. And as we dug into this a bit further, it does make sense for how you think about these things and how you build them to customers. Specifically, if I want to run this, I log into cloud.oracle.com and sign up for it there and pay you over on that side of the world. This does not show up on my AWS bill. What drove that decision? Okay, so a couple of things. So one clarification is that the site people log into is cloud.mysql.com. So that's where they come to, cloud.mysql.com. So that's where they come to, cloud.mysql.com.

Starting point is 00:17:30 My apologies. I keep forgetting that you folks have multiple cloud offerings and domains. They're kind of a thing. How do they work? Given I have a bad domain buying habit myself, I have no room to judge. So they come to cloud.mysql.com. From there, they can provision an instance. And we, as Oracle or MySQL, go ahead and provision an instance. And we as like, you know, Oracle or MySQL, go ahead and create an instance in AWS, in the Oracle tenancy, from where customers can then, you know, access the data which we need AWS and such. Now, what we want to provide the customers

Starting point is 00:17:55 is a very seamless experience that they just come to cloud.mysql.com. And from there, they can do everything, provisioning an instance, running the queries, payment and such. So this is one of the reasons that we want customers to just to be able to come to the site, cloud.mysql.com and take care of the billing and such. Now, the other thing is that, okay, why not allow customers to pay from AWS, right? Now, one of the things over there is that if you were to do that and there's a customer,

Starting point is 00:18:23 they'll be like, hey, I got to pay something to AWS, something to Oracle. So we preferred it would be better to have a one-stop shop. And since many of these are already Oracle customers, it's helpful to do it this way. Another approach you could have taken, and I want to be very clear here that I am not suggesting that this would have been a good idea. But an approach that you could have taken would have been to go down the, we're an AWS partner rabbit hole, and we're going to provide this to customers on the AWS marketplace.

Starting point is 00:18:55 Because according to AWS, that's where all of their customers go to discover new softwares. Yeah, first, that's a lie. They do not. But aside from that, what was it about that marketplace model that drove you to a decision point where, okay, at launch, we are not going to be offering this on the AWS marketplace? And to be clear, I'm not suggesting that was the wrong

Starting point is 00:19:17 decision. Right. The main reason is we want to offer the MySQL HeatWave service at the least expensive cost to the user, right? Or like the least cost. If you were to like have MySQL HeatWave service at the least expensive cost to the user, right, or like the least cost. If you were to like have MySQL HeatWave in the marketplace, AWS charges a premium which the customers would need to pay. So we just didn't want the customers

Starting point is 00:19:35 to have to pay this additional premium just because they can now search this thing from the marketplace. Just really to like save costs for the customer. The value of the marketplace, from my perspective, has been effectively not having to deal as much with customer procurement departments because, well, AWS is already on the procurement approved list, so we're just going to go ahead and take the hit to wind up making it accessible from that perspective and calling it good. The downside to this is that increasingly, as customers are making larger and longer-term

Starting point is 00:20:09 commitments that are tied to certain levels of spend on AWS, they're increasingly trying to drag every vendor with whom they do business into their AWS bills so they can check those boxes off. And the problem that I keep seeing with that is vendors who historically have been doing just fine, have great working relationships with a customer, are reporting that suddenly customers are coming back with, yeah, so for our contract renewal, we want to go through the AWS marketplace. In return, effectively, these companies are then just getting a haircut off whatever it is they're able to charge their customers, but receiving no actual value for any of this. It attenuates the relationship by introducing a third party into the process, and it doesn't make anything better from the vendor's point of view, because they already had something functional and working. Now they just have to pay a commission on it to AWS,

Starting point is 00:21:05 who it seems is pathologically averse to any transaction happening where they don't get a cut on some level. But I digress. I just don't like that model very much at all. It feels coercive. That's absolutely right. That's absolutely right.

Starting point is 00:21:19 And we thought that, yes, there is some value to maybe going to marketplace, but it's not worth the additional premium customers would need to pay. Totally agree. Here at the Duckbill Group, one of the things we do with, you know, my day job is we help negotiate AWS contracts. We just recently crossed $5 billion of contract value negotiated. It solves for fun problems, such as how do you know that your contract that you have with AWS is the best deal you can get? How do you know you're not leaving money on the table? How do you know that you're not doing what I do on this podcast and on Twitter constantly and sticking your foot in your mouth?

Starting point is 00:21:58 To learn more, come chat at duckbillgroup.com. Optionally, I will also do podcast voice when we talk about it. Again, that's duckbillgroup.com. Optionally, I will also do podcast voice when we talk about it. Again, that's duckbillgroup.com. It's also worth pointing out that in Oracle's historical customer base, by which I mean the last 40 years that you folks have been in business, you do have significant customers with very sizable estates, a lot of your cloud efforts have focused around, I guess we call it an Oracle-specific currency, Oracle credits, which is similar to the AWS style of currency, just for a different company in different ways. One of the benefits that you articulated to me relatively early on was that by going through cloud.mysql.com, customers with those credits,

Starting point is 00:22:46 which can be in sizable amounts based upon various differentiating variables that change from case to case, and apply that to their use of MySQL HeatWave on AWS. Right. So in fact, just for starters, right, what we encourage customers is we offer some free credits for customers to try a service on OCI of $300.

Starting point is 00:23:07 And that's the same thing, the same experience we would like customers who are trying HeatWave on AWS to get. Yes, so you're right. So this is the kind of consistency we want to have. And yet another reason why cloud.mysql.com makes sense as the entry point for customers to try the service. There was a time where I would have struggled not to laugh in your face at the idea that we're talking about something in the context of an Oracle database. And well, there's $300 in credit. What could I get for that hung up on? No, a surprising amount when it comes to these things. I feel like that opens up an entirely new universe of experimentation. And let's see how this thing actually works

Starting point is 00:23:48 with this workload. And lets people kick the tires on it for themselves in a way that, oh, we have this great database. Well, can I try it? Sure, for $8 million, you absolutely can. Well, it can stay great and awesome over there because who wants to take that kind of a bet? It feels like it's a new world

Starting point is 00:24:04 in a bunch of different respects. i'm i just can't make enough noise about how glad i am to see this transformation happening yeah absolutely right so just think about it so you're getting my sql and heatwave together for just shy of 10 cents an hour right so what you could get for 300 is 3 000 hours for my sqlave instance, which is very good for people to try for free and then decide if they want to go ahead with it. One other, I guess, obnoxious question that I love to ask. It's not really a question so much as a statement. That's part of the first thing that makes it really obnoxious. But it always distills down to the following that upsets product people left and right, which is, I don't get it.

Starting point is 00:24:46 And one of the things that I didn't fully understand at the outset of how you were structuring things was the idea of separating out heatwave from its constituent components. I believe it was autopilot, if I'm not mistaken. It was effectively different SKUs that you could wind up opting to go for. And okay, if I'm trying to kick It was effectively different SKUs that you could wind up opting to go for. And okay, if I'm trying to kick the tires on this and contextualize it as someone for whom the world's best database is Route 53, then it really felt like a additional decision point that I wasn't clear on the value of. And I'm still not entirely sure on the differentiation point and the value there, but now you offer

Starting point is 00:25:25 it bundled as a default, which I think is so much better from the user experience perspective. Okay. So let me clarify a couple of things. Please. Databases are not my forte. So expect me to wind up getting most of the details hilariously wrong. So MySQL Autopilot provides machine learning-based automation for various aspects of the MySQL service. Very popular. There is no charge for it. It is built in to MySQL HeatWave. There is no

Starting point is 00:25:51 additional charge for it. So there never was any skew for it. What you're referring to is we have had a skew for the MySQL node or the MySQL instance, and there's a separate skew for HeatWave. The reason there is a need to have a different SKU for these two is because you always only have one node of MySQL. It could be running on one core or multiple cores, but it's always one node. But the HeatWave, it's a scale-out architecture,

Starting point is 00:26:18 so you can have multiple nodes. The users need to be able to express how many nodes of HeatWave are they provisioning. So that's why there is a need to have two SKUs and we continue to have those two SKUs. What we are doing now differently is that when users instantiate a MySQL instance, by default, they always get the HeatWave node associated with it. So they don't need to make the decision to say, okay, when to add HeatWave.

Starting point is 00:26:44 You always get HeatWave along with the MySQL instance. And that's what I was saying. A combination of both of these is, you know, like just about 10 cents an hour. If for whatever reason they decide that they do not want heatfib, they can turn it off and then the price drops to half. But what we're providing is the AWS service that HeatWave is turned on by default. Which makes an awful lot of sense. It's something that lets people opt out if they decide they don't need this as they continue to scale out. But for the newcomer who does not, in many cases, in my particular case, have a nuanced understanding of where this offering starts and stops, it's clearly the right decision of rather than, oh yeah, the thing you were trying

Starting point is 00:27:26 and it didn't work super well. Well, yeah, if you enable this other thing, it would have been awesome. Well, great, please enable it for me by default and let me opt out later in time as my level of understanding deepens. That's right. And that's exactly what you're doing.

Starting point is 00:27:39 And this was a feedback we got because many, if not most of our customers would want to have HeatWave. And we just kind of mitigating them from going to one more step. It's always enabled by default. As far as I'm aware, you folks are running this effectively as any other AWS customer might, where you establish a private link connection to your customers in some cases, or give them a public or private endpoint where they can wind up communicating with this service. It doesn't require any favoritism or special permissions from AWS themselves that they wouldn't give to any

Starting point is 00:28:18 other random customer out there, correct? Yes, that is correct. So for now, we are exposing this thing as a public endpoint. In the future, we have plans to support the private endpoint as well. But for now, it's public. Which means that foundationally, what you're building out is something that fits into a model that could work extraordinarily well across a variety of different environments. How purpose-tuned is the heatwave installation you have running on AWS for the AWS environment versus something that is relatively agnostic, could be dropped into any random cloud provider up to it, including the terrifyingly obsolete rack I have in the spare room? So as I mentioned, when we decided to offer MySQL Heatwave on AWS, the idea was that, okay, for the AWS customers, we now want to have an offering

Starting point is 00:29:05 which is completely optimized for AWS, provides the best price performance on AWS. So we have determined which instance types underneath will provide the best price performance, and that's what we have optimized for. So I can tell you, like in terms of many of, for instance, take the case of the cache size of the underlying processor we are using on AWS is different than what we're using for OCI.

Starting point is 00:29:30 So we have gone ahead, made these optimizations in our code, and we believe that our code is really optimized now for the AWS infrastructure. I think that that makes a fair deal of sense because, again, one of the big problems AWS has had is the proliferation of EC2 instance types to the point now where the answer is super easy to, are you using the correct instance type for your workload? Because that answer now is, of course not. Who could possibly say that they were with any degree of confidence? But when you take the time to look at a very specific workload that's going to be scaled out, it's worth the time investment to figure out exactly how to optimize things for price and performance given the constraints. Let's be very clear here. I would argue that the

Starting point is 00:30:15 better price performance for heatwave is almost certainly not going to be on AWS themselves if for no other reason than the joy that is their data transfer pricing, even for internal things moving around from time to time. Personally, I love getting charged data transfer for taking data from S3, running it through AWS Glue, putting it into a different S3 bucket, accessing it with Athena, then hooking that up to Tableau as we go down and down and down the spiraling rabbit hole that never ends. It's not exactly what I would call well-optimized economically. Their entire system feels almost like it's a rigged game on some level. But given those constraints, yeah, dialing it in and making it cost-effective is absolutely something that I've watched you

Starting point is 00:31:00 folks put significant time and effort into. So I'll make two points right to the questions. First is, yes, I just want to be clear about it, that when a user provisions MySQL HeatFab via cloud.mysql.com and we create an instance in AWS, we don't give customers a multitude of things to choose from. We have determined which instance type is going to provide the customer the best price performance, and that's what we provision. So the customer doesn't even need to know or care, is it going to be like AMD? Is it going to be Intel? Is it going to be like ARM? So it's something which we have predetermined and we have optimized for it. That's first. The second point is in terms of the price performance. So you're absolutely right

Starting point is 00:31:43 that for the class of customers who cannot migrate away from AWS because of the price performance. So you're absolutely right, that for the class of customers who cannot migrate away from AWS because of the egress cost or because of the high latency because of AWS, right? Sure, MySQL HeatWave on AWS will provide the best price performance compared to other services in AWS, like Redshift or Aurora or Snowflake, right?

Starting point is 00:32:03 But if customers have the flexibility to choose a Cloud of their choice, it is indeed the case that customers are going to find that running MySQL HeatWave on OCI is going to provide them by far the best price performance. The price performance of running MySQL HeatWave on OCI is indeed better than MySQL HeatWave on AWS. Just because of the fact that when we are running the service in AWS, we are paying the list price on AWS.

Starting point is 00:32:30 That's how we get the gear. Whereas with OCI, things are a lot less expensive for us. But even when we are running on AWS, we are very, very price competitive with other services. And as you have probably seen from the performance benchmarks and such, what I'm very intrigued about is that we are able to run a standard workload like something like TPCS and offer seven times better price performance while running an AWS compared to Redshift.

Starting point is 00:32:56 So what this goes to show is that we are really passing on the savings to the customers and clearly the Redshift is not doing a good job with performance or like, you know, they're charging too much. But the fact that we can offer seven times better price performance than Redshift in AWS speaks volumes, both about our architecture and how much of savings we are passing to our customers. What I love about this story is that it makes testing the waters

Starting point is 00:33:21 of what it's like to run MySQL HeatWave a lot easier for customers, because the barrier to entry is so much lower, where everything you just said, I agree with. It is more cost-effective to run on Oracle Cloud. I think there are a number of workloads that are best placed on Oracle Cloud. But unless you let people kick the tires on those things where they happen to be already, it's difficult to get them to a point where they're going to be able to experience that themselves. This is a massive step on that path. Yep. Agree. I really want to thank you for taking time out of your day to walk us through exactly how this came to be and what the future is going

Starting point is 00:34:00 to look like around this. If people want to learn more, where should they go? Oh, they can go to oracle.com slash MySQL HeatWave. And there they can get a lot more information about the capabilities of MySQL HeatWave, what we are offering in AWS, price performance. By the way, all the price performance numbers I was talking about, all the scripts are available publicly on GitHub. So we welcome, we encourage customers

Starting point is 00:34:24 to download the scripts from GitHub, try it for themselves. And all of this information is available from oracle.com slash MySQL where they can get this detailed information. And we will, of course, put links to that in the show notes. Thank you so much for your time. I appreciate it.

Starting point is 00:34:39 Sure thing, Corey. Thank you for the opportunity. Nipun Agarwal, Senior Vice President of MySQL HeatWave. I'm cloud economist, Corey Quinn, and this is Screaming in the opportunity. Nipun Agarwal, Senior Vice President of MySQL HeatWave. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment.

Starting point is 00:35:00 You will then be overcharged for the data transfer to submit that insulting comment, and then AWS will take a percentage of that just because they're obnoxious and can.

Screaming in the Cloud - Replay - HeatWave and the Latest Evolution of MySQL with Nipun Agarwal

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.