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

Episode Date: October 6, 2022

About NipunNipun Agarwal is a Senior Vice President, MySQL HeatWave Development, Oracle. His interests include distributed data processing, machine learning, cloud technologies and security. Nipun was part of the Oracle Database team where he introduced a number of new features. He has been awarded over 170 patents.Links Referenced:Oracle: https://oracle.comMySQL HeatWave info: https://www.oracle.com/mysql/MySQL Service on AWS and OCI login (Oracle account required): https://cloud.mysql.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is brought to us in part by our friends at Datadog. Datadog's a SaaS monitoring and security platform that enables full stack observability for developers,

IT operations, security, and business teams in the cloud age. Datadog's platform, along with 500-plus vendor integrations, allows you to correlate metrics, help teams troubleshoot and collaborate more effectively prevent downtime and enhance performance and reliability try datadog in your environment today with a free 14-day trial and get a complimentary t-shirt when you install the agent to learn more visit datadoghq.com screaming in the cloud to get started. That's www.datadoghq.com slash screaming in the cloud. This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you want to learn more about how they view this, check out their blog.

It's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit sysdig.com and tell them that I sent you. That's S-Y-S-D-I-G dot com. And my thanks to them for their continued support of this ridiculous nonsense. 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. 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. 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, 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 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. 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.

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 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 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 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 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 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, is going to be fairly sarcastic, which is 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 is that customers of MySQL or customers of MySQL-compatible databases, whether it's Aurora or whether it's RDS MySQL, or even 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. So what we found is that if you were to offer MySQL heat field 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 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 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? 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 scalar processing, and it's been optimized for the cloud. So when we decided to offer MySQL HeatWave on AWS,

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, right? So we have, it's not the case that we're just taking 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 to 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. 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.

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, 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 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, right? 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 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. Now, 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. It's not stale. Whereas 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 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 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. 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 towards 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 on 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, 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 like 12.5 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 shape and yeah, it's very, very affordable. It's about just shy of 10 cents an hour. 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.

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 like, you know, Oracle or MySQL, go ahead and create an instance in AWS in the Oracle tenancy from where customers can then access the data, which will be in AWS and such. Now, what we want to provide the customers is a very seamless experience that they just come to cloud.mysql.com, and from there they can do everything, right? 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, 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.

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, right? Or like the least cost. If you were to like have MySQL HeatWave in the marketplace, it always charges a premium which the customers would need to pay.

So we just didn't want the customers to have to pay this additional premium just because they can now source 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 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, 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. And we thought that, yes, there is some value to maybe going to marketplace, but it's not what the additional premium customers would need to pay.

Totally agree. This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve and occasionally create problems, but not when it's an on-call fire drill at four in the morning. Software problems should drive innovation and collaboration, not stress and sleeplessness and threats of violence. That's why so many developers are realizing the value

of AWS AppConfig feature flags. Feature flags let developers push code to production, but hide that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development.

You can seamlessly incorporate AppConfig feature flags into your AWS or cloud environment and ship your features with excitement, not trepidation and fear. To get started, go to snark.cloud slash appconfig. That's snark.cloud slash appconfig. 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'd 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, 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. And that's the same thing, the same experience. We would like customers who are trying Heatwave on AWS to get. Yes, 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 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 and it in a bunch of different respects and 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 sequel and he tripped together for just shy of 10 cents an hour, right? So what you could get

for $300 is 3,000 hours for MySQL HeatWave 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. 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 the tires on this and contextualize it as someone for whom the world's best database is Route 53, then it really felt like an 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 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. Sure.

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 additional charge for it, right? So there never was any SKU 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 heat wave. The reason there is a need to have a different skew 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 heatwaves, it's a scale-out architecture, so you can have multiple nodes. So 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. You always get heatwave along with the MySQL instance. And that's what I was seeing. A combination of both of these is just about 10 cents an hour.

If for whatever reason they decide that they do not want heatwave, they can turn it off and then the price drops to half. But what we are 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 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 we're doing. And this was a feedback we got because many, if not most of our customers, would want to have HeatWave, and we're 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 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 to Heatray on AWS, the idea was that, okay, for the AWS customers, we now want to have an offering 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. 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 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 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 HeatWave 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 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 out in AWS like Redshift or Aurora or Snowflake, right? 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. 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 TPC-Edge, and offer seven times better price performance while running in AWS compared to Redshift. So what this goes to show is that we are really passing on the savings to the customers, and clearly, Redshift is not doing a good job with performance or 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 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 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 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 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. Sure thing, Kauri. Thank you so much for your time. I appreciate it. 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 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. 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't. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point.

Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.