Screaming in the Cloud - Cranking Up the Heatwave with Nipun Agarwal

Episode Date: September 23, 2021

About NipunNipun Agarwal is Vice President, MySQL HeatWave and Advanced 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:HeatWave: https://oracle.com/heatwave

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. You could go ahead and build your own coding and mapping notification system, but it takes time, and it sucks.

Alternately, consider Courier, who's sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability, and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them that I sent you, and watch them wince because everyone does when you bring up my name. That's the glorious part of being me.

Once again, you could build your own notification system, but why on God's flat earth would you do that? Visit courier.com today to learn more. This episode is sponsored in part by our friends at VMware. Let's be honest, the past year has been far from easy due to, well, everything. Caused us to rush cloud migrations and digital transformation, which of course means long hours refactoring your apps, surprises on your cloud bill, misconfigurations, and headaches for everyone trying to manage disparate and fractured cloud environments. VMware has an answer for this. With VMware's multi-cloud solutions, organizations have the

choice, speed, and control to migrate and optimize applications seamlessly without recoding, take the fastest path to modern infrastructure, and operate consistently across the data center, the edge, and any cloud. I urge you to take a look at vmware.com slash go slash multicloud. You know my opinions on multicloud by now, but there's a lot of stuff in here that works on any cloud. But don't take it from me. That's vmware.com slash go slash multicloud, all one word. And my thanks to them again for their sponsorship of my ridiculous nonsense. Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode

is slightly off the beaten track. Normally in tech, we tend to find folks that have somewhere between an 18 to 36 month average tenure at companies, and that's great. However, let's do the exact opposite of that today. My guest is Nipun Agarwal, who's the VP of MySQL HeatWave and Advanced Development at Oracle, where you've been an employee for 27 years, is it? That's absolutely right. 27 years, and that was my first job out of school. So, yeah. First, thank you for joining me. It is always great to talk to people who have focused on an area that I only make fun of from a distance. In this case, databases, which, you know, DNS works well enough for most use cases, but occasionally customers have other constraints.

You are clearly at or damn near at the top of your field. In my pre-show research, I was able to on earth that you have, what is it now, 170, 180 filed patents that have been issued? That's right. 180 issued patents. You clearly know what you're doing when it comes to databases. Thank you for the opportunity. Yes, thank you. So being a VP at Oracle, but starting off as your first job, there's almost a mailroom to the executive suite style story. We don't see those anymore. In most companies, it very much feels like the path

to advance is to change jobs to other companies. It's still interesting seeing that that's not always the path forward for some folks. I think that the folks who have been at companies for a long time need more examples and role models to look at in that sense, just because it is such a uncommon narrative these days. You're not bouncing around between four companies. Yeah, I've been lucky enough to have joined Oracle. And although I have been at Oracle, I've been in multiple teams at Oracle, and there has been a great opportunity of talent, colleagues, and projects, right? Where even to this day, I feel that I have like a lot more to learn and there are opportunities within the company to like learn and to grow.

So no, I've had an awesome ride. Let's dive in a little bit to something that's been making the rounds recently. Specifically, you've released something called HeatWave, which has been boasting some frankly borderline unbelievable performance benchmarks. And of course, everyone loves to take a crack at Oracle for a variety of reasons. So Twitter is very angry, but I've learned at some point through the course of my career to

disambiguate Twitter's reactions from what's actually happening out there. So let's start at the beginning. What is HeatWave? HeatWave is an in-memory query accelerator for MySQL. It accelerates complex, long-running LD queries. The interesting thing about HeatWave is with HeatWave, we now have a single MySQL database, which can run all your applications, whether they're OLTP, whether they're OLTP, whether they're mixed workloads, or whether they're analytics, without having to move the data out of MySQL.

Because in the past, people would need to move the data from MySQL to some other database for running analytics. So people would end up with two different databases. With this single database, no need for moving the data, and all existing tools and applications which work with MySQL continue to work, except they will be much faster. That's what HeatWave is. The benchmarks that you are publishing are fairly interesting to me. Specifically, the ones that I've seen are you've classified HeatWave as six and a half times faster than Amazon Redshift, seven times faster than Snowflake, nine times faster than BigQuery,

and a number of other things, and 1,400 times faster than Amazon Aurora. And what's interesting to me about the things that you're naming is they're not all data warehouse style stuff. Aurora, for example, is Amazon's interpretation of an in-house developed managed database service named after a Disney princess. And it tends to be aimed at things that are not necessarily massive scale. What is the sweet spot, I guess, of HeatWave's data sizes when it comes to really being able to shine? So there are two aspects where customers are going to benefit from heatwave. One characteristic is the data size, but the other characteristic

is the complexity of the queries. So let's first do the comparison with Aurora, and that's a very good question. The 1400 times comparison we have shown is if you take the TPC-H queries on a four terabyte workload,

and if you run them, that's what you're going to see. Now, the interesting thing is this. Not only is it 1,400 times faster, it's also at half the price. Because for most of these systems, if you throw more gear, if you throw more hardware, the performance would vary. So it's very important to go with how much of performance and at what price, right? So for pure analytics, say for four terabytes, it is 1400 times faster at half the price. So HeatFake provides 2800 times better price performance compared to Alibaba for pure analytics. Now let's take the other extreme, 100 gigabytes, right, which is a much smaller your bread and butter database. And this is for mixed workloads. So something like a CH gigabytes, which is a much smaller your bread and butter database. And this is for mixed workloads. So something like a CH benchmark, which has a combination

of say some TPCC transactions, and then some derived TPCH queries, which is the CH benchmark. Here, we have 42 times advantage price performance over Aurora, because we are 42% of the cost, less than half the cost of Aurora. And for the complex queries, we are about 18 times faster. And for pure OLTP, we are at par. So the aggregate comes out to be about 42 times better. So the mileage varies depending upon the data size and depending upon the complexity of the queries.

So in the case of Aurora, it will be anywhere from 42 times better price performance all the way to 2,800. Does this have an upper bound, for example? If we take a look at something like Redshift or something like Snowflake, where they're targeting petabyte scale workloads at some point, that becomes a very different story for a lot of companies out there. Is that something that this can scale to? Or is there a general reasonable upper bound of, okay, once you're above X number of terabytes, it's probably good to start looking at tiering data out or looking at a different solution? We designed HeatFaith primarily for those customers who had to move the data out of MySQL database into some other database for running analytics. The upper bound for the data in the MySQL database is 64 terabytes. Based on the demand and such VFC,

we support 32 terabytes processing in HeatWave at any given point in time. You can still have 64 terabytes in the MySQL database, but the amount of data you can load into the HeatWave cluster at any given point in time is 32 terabytes. Which is completely reasonable. I would agree with you from not having much database exposure myself in the traditional sense, but from a cloud economics standpoint alone, anytime you have to move data to a

different database for a different workload, you're instantly jacking costs through the roof. Even if it's just the raw data volumes, you don't have to store it in two different places instead of one. Plus, in many cases, the vagarities of data transfer pricing in many places wind up meaning that you're paying money to move things out. There's a replication story, there's a sync factor, and then it just becomes a management overhead problem. If there's a capacity to start using the data where it is in more intelligent ways, that alone has a massive economic win just from a time it takes your team to not have to

focus on changing infrastructure and just going ahead to run the queries. If you want to start getting into the weeds of all the different ways something like this is an economic win, there's a lot of angles to look at it from. That's an excellent point. I'm very glad you brought it up. So now let's take the other set of benchmarks we were talking about. Snowflake. So heatwave is seven times faster at one-fifth the cost. So it's about 35 times better price performance compared to, let's say, Redshift Aqua, six and a half times faster at half the cost. So 13 times better price performance. And it goes on and on. Now, these numbers I was quoting is for 10 terabytes TPC-H queries, right? And the point which you said is very, very valid. When we are talking about the cost for these other systems,

it's only the cost for analytics without including the cost of the source database or without including the cost of moving the data or managing two different databases. Whereas when you're talking about the cost of HeatWave, this is the cost which includes the cost of both transaction processing as with the analytics. So it's a single database, all the cost is included. Whereas for these other vendors, it's only the cost of the analytic database. So the actual cost to a user is probably going to be much higher with these other databases. So the price performance advantage with HeatFib will perhaps be even higher. Tell me a little bit about how it works.

I mean, it's easy to sit here and say, oh, it's way faster and it's better in a bunch of benchmark stuff. And we will get into that in a little bit. But it's described primarily as an in-memory query accelerator. Naively, I think, oh, it's just faster because instead of having data that lives on disk, it winds up having some of it live in RAM. Well, that seems simple and straightforward. Like, oh, yeah, I'm going to go out on a limb

and assume that there aren't 160 patents tied to the idea that RAM is faster than disk. There's clearly a lot more going on. How does this work? What is it, foundationally? So the thing to realize is HeatWave has been built from the ground up for the cloud, and it is optimized for the Oracle Cloud.

So let's take these things one at a time. When I say designed from the ground up for the cloud, we have actually invented and implemented new algorithms for distributed query processing, which is what gives us such a good advantage in terms of operations like joint processing, window functions, aggregations, right? So we have come up and invented, implemented new algorithms for distributed query processing. Secondly, we have designed it for the cloud. And by that, what I mean is, A, we have a lot of emphasis on scalability, that it scales to thousands of cores with a very, very good scale factor, which is very important for

the cloud. The next angle about the cloud is that not only have we optimized it for the cloud, but we have gone with commodity cloud services, meaning, for instance, when you're looking at the storage, we are looking at the least expensive price. So, for instance, we use object store. We don't use, for instance, locally attached SSDs because they'll be expensive. Similarly, for compute, instead of using Intel, we use AMD shapes because they're less expensive. Similarly, networking, standard networking. And all of this has been optimized for the specific Oracle Cloud

infrastructure shapes we have, for the specific VMs we use, for the specific networking bandwidth we get, for the object store bandwidth and such. So that's the third piece, optimized for OCI. And the last bit is pervasive use of machine learning in the service. So a combination of these

four things, designed for the cloud, using commodity cloud services, optimized for the Oracle Cloud Infrastructure, and finally, the pervasive use of machine learning is what gives us very good performance, very good scale, at a very inexpensive price. I want to dig in to the idea of the pervasive use of machine learning. In many cases, machine learning is the answer to, how do I wind up bilking a bunch of VCs out of money? And Oracle is not a venture-backed company at this stage of its existence. It is a very large, publicly traded entity. You have no need to do that. And I would also further accept that this is one of those

bounded problem spaces where something that looks machine learning-like could do very well. Is that based upon what it observes and learns from data access patterns? Is it something that it learns based from a specific workload in question? What is it gathering? And is it specific to individual workloads that a given customer has? And is it specific to individual workloads that a given customer has? Or is it holistically across all of the database workloads that you see in Oracle Cloud? So there are multiple paths to this question.

The first thing is, and I think as you're noting, that with that cloud, we have a lot more opportunity for automation, because we know exactly what is the hardware stack, we know the software stack, we know the configuration parameters. Oh, as hell as other people's data centers, for sure. And the approach we have taken for automation is machine learning-based automation

because one of the big advantages is that we can have a model which is tailored to a specific instance. And as you run more queries, as you run more workloads, the system gets more intelligent. And we can talk about that maybe later about specific things which make it very, very compelling. The third thing, I think, which you are alluding to is that there are two aspects in machine learning, data and the models or the algorithms. So the first thing is we have made a lot of enhancements, both to the MySQL engine, as well as HeatWave, to collect new kinds of data. And by new kinds of data, I mean that not only do we collect statistics of data, but

we collect statistics of, say, the queries, that what was the compilation time, what was the execution time. And then based on this data which we're collecting, we'd have then come up with very advanced algorithms, machine learning algorithms, which are again, a lot of them, there's like patterns or IP which we have built on top of the existing state of art. So for instance, taking these statistics and extrapolating them on larger data sizes.

That's completely an innovation which we did in-house. How do we sample a very small percentage of the data and still be accurate? And finally, how do we come up with these machine learning models which are accurate without hiring an army of engineers? That's because we invented our AutoML, which is very efficient. So that's basically the ecosystem of the machine learning which we have, which has been used to provide this. It's easy for folks to sit there and have a bunch of problems with Oracle for a variety of reasons, some of which are no longer germane, some of which are, I'm not here to judge. But I think it's undeniable, though it sometimes gets

eclipsed by people's knee-jerk reactions, the reason that Oracle is in so many companies that it is in is because it works. You folks have been pioneers in the database space for a very long time, and that's undeniable. If it didn't deliver performance that was untouchable for a long time, it would not have gotten to the point where you now are, where it is the database of record for an awful lot of shops. And I know it's somehow trendy sometimes for the startup set to think, oh, big companies are slow and awful. All innovation comes out of small, scrappy startups here. But your customers are not fools. They've made intelligent decisions based upon constraints that they're working within and problems that they need to solve. And you still have an awful

lot of customers that are not getting off of Oracle anytime soon because it works. It's one of those things that I think is nuanced and often missed. But I do feel the need to ask about the lock-in story. Today, HeatWave is available only on the managed MySQL service in Oracle Cloud, correct? Correct. Is there any licensing story tied to that? In other words, to, well, if I'm going to be using this, I need to wind up making a multi-year commitment. I need to get certain support things as well. The traditional on-premises Oracle story. Or is this an actual cloud service in that you pay for what you use while you use it,

and when you turn it off, you're done, in theory. In practice, we know in cloud economics, no one ever turns anything off until the company goes out of business. So it's exactly the latter of what you said, that this is a managed service. It's pay as you go. You pay only for what you consume. And if you decide to move on, there's absolutely no license or anything which is what you consume. And if you decide to move on, there's absolutely no license or anything which is holding you back. The second thing, and I'm glad you brought it up, about the window locking.

One of the very important things to realize about HeatWave is A, it's just an accelerator for MySQL. But in the process of doing so, we have not introduced any proprietary syntax. If customers have their MySQL application running on some other Cloud, they can very easily migrate to OCI and try MySQL heatwave. But for whatever reason,

if they don't like it and they want to move out, there is absolutely nothing which is holding them back. The ease at which they can come in, with the same ease they can walk out, because we don't have any vendor lock-in. There is absolutely no proprietary extensions to HeatWare. There is the counter-argument as far as lock-in goes. And we see this sometimes with companies we talk to that we're considering Google Cloud Spanner as an example. It's great, and you can use it in a whole bunch of different places and effectively get ACID compliance-like behavior across multiple regions,

and you don't have to change any of the syntax of what it is you're using, except the lock-in there is one of a strategic or software architecture lock-in, because there's nothing else quite like that in the universe, which means that if you're going to migrate off of the single cloud where that's involved, you have to re-architect a lot. And that leads to a story of lock-in. I'm curious as to whether you're finding that customers are considering that as far as the performance that you're giving for MySQL querying is apparently unparalleled in the rest of the industry. that leads to a sort of lock-in itself when people get used to that kind of responsiveness and build applications that expect that kind of tolerances. At some point, if there's nothing else in the industry like it, does that mean that they find

themselves de facto locked in? If you were to talk about some functionality which we are offering, which no one else is offering, perhaps you could kind of make the case. But that's not the case for performance. Because when we are so much faster, right? So suppose I say that, okay, we are so much faster, like we are six and a half times faster than Redshift at half the cost. Well, if someone wanted the same performance, they can absolutely run on Redshift on a much larger cluster and pay a lot more, right?

So if they want the best performance at the best price, they can come to Oracle Cloud. If they want the same performance, but they will have to pay more, they can go anywhere else. So I don't think that's a vendor lock-in at all. That's a value which we are bringing in, that for the same performance, we are much cheaper. Or you can have that kind of a balance that we are faster and cheaper. So there is no lock-in. So it's not to say that, okay, we have made some extensions to MySQL, which are only available

in our cloud. That is not at all the case. Now, for some other vendors and for some other applications, you brought up Spanel, that's one. But we have had multiple customers of MySQL who, when they were trying Google BigQuery, they mentioned this aspect that, okay, Google BigQuery has these proprietary extensions and they feel locked in. That is not the case at all with HeatWave. This episode is sponsored by our friends at Oracle HeatWave,

a new high-performance query accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel. Well, MySquirrel has long been the world's most popular open source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work, while also performing 1,100 times faster than Amazon Aurora and 2.5 times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. I do want to call out, just because it seems like there's a lies, damned lies, and database benchmarks story here, where, for example, Azure for a while was doing a campaign where they were five times less expensive for database workloads than AWS,

until you scratch beneath the surface and realize it's because they're playing ridiculous games with licensing, making it very expensive to run a Microsoft SQL Server on anything that wasn't Azure. Customers are not necessarily as credulous as they once were when it comes to benchmarking. And Oracle, for a long time, hasn't really done benchmarking and, in fact, has actively discouraged it. For HeatWave, you've not only published benchmarks, which, okay, vendors can say anything they want, and I'm going to wait until I see independent returns, but you put not just the benchmarks, but data sets and your entire methodology on the GitHub as well.

What led to that change? It seems like the least Oracle-like thing I could possibly imagine. I can take credit for the idea. The idea actually was from our chief marketing officer. That was really his idea. But here is the reason why it makes a lot more sense for us to do it for MySQL HeatWave. MySQL is pervasive. Pretty much any cloud vendor you can think about has a MySQL-based managed service.

And obviously, MySQL runs on-premise like a lot of customers and applications do it. It's one of the baseline building blocks of any environment. I don't even need to be in a cloud. I can get MySQL working somewhere. Everyone has it. And if not, why don't you? And I can build it in a VM myself in 20 minutes. That's right.

It is a de facto standard. That's right. So given that is the case, and many of the cloud vendors are innovating on top of it, which is great. How do you compare the innovation or the value proposition of cloud vendor A with us? So for that, what we felt was that it is very important and very fair that we publish our scripts so that people can run those same scripts with HeatWave as well as with other cloud offerings and make a determination for themselves.

So given the popularity of MySQL and given that pretty much all cloud vendors provide an offering of MySQL, and many of them have enhanced it, in order for customers to have an apples-to-apples comparison, it is imperative that we do this. I haven't run the benchmarks myself just yet, just because it turns out there's a lot of demands on my time. And also, as mentioned, I'm not a deep database expert unless it comes to DNS. And I keep waiting for people to come back with an, aha, here's why you're completely comprised of liars. And I haven't heard any of that. I've heard edges and things here about like,

well, if you add an index over here, it might speed things up a bit. But nothing that leads me to believe that it is just a marketing story. It is a great marketing story, but things like this fall apart super quickly in the event that it doesn't stand up to engineering scrutiny. And it's been out long enough that I would have fully expected to have heard about it. Lord knows if anyone is listening and has thoughts on this, I will be getting some letters after this episode, I expect. But I've come to expect those. Please feel free to reach out. I am always thrilled to do follow-up episodes and address things like this. When does it make sense, from your perspective, for someone to choose HeatWave on top of the

Oracle Cloud MySQL service instead of using some of the other things we've talked about, Aurora, Redshift, Snowflake, et cetera? When does that become something that a customer should actively consider? Is it for net new workloads? Should they consider it for migration stories? Should they run their database workloads in Oracle Cloud and keep other stuff elsewhere? What is the adoption path that you see that tends to lead to success? All customers of MySQL or all customers of any open source database, those would be absolutely people who should consider MySQL HeatWave for the very simple reason.

First, regardless of the workload, whether it is OLTP only or mixed workloads or analytics, the cost is going to be significantly lower. I'll say at least it's going to be half the cost. In most of the cases, it's probably going to be less than half the cost. Right off the bat, customers save half the cost by moving to SQL HeatWave.

Then depending upon the workload you have, as you have more complex queries, the performance advantage starts increasing. If you were just running only OLTP, if you only had transactions, and you didn't have any complex queries, which is very unlikely for real-world applications, but even if that was the case, you're going to save 60% by going to MySQL Heatflare. But as you have more complex queries, you will start finding that the net advantage you're going to get with performance

is going to keep increasing and will go anywhere from 10 times aggregate to as much as 1400 times. So all open source MySQL based applications, they should consider moving. Then you have, you mentioned about Snowflake, Redshift and such. For all of them, it depends on what the source database is and what is it that they're trying to do. If they're moving data from, say, some open source databases, if they're ETLing from MySQL, not only will MySQL HeatWave be much faster and much cheaper, but there's going to be a tremendous value proposition to the application because they don't need to have two different applications for two different databases. They can come back to MySQL, they don't need to have two different applications for two

different databases. They can come back to MySQL. They can have a single database on which they can run all their applications. And then again, you have many of these cloud-native applications are born in the cloud where people may be looking for a simple database which does the job. And this is a great story, both in terms of cost as well as in terms of performance. It's a single database for all your applications, significantly reduces the complexity for users.

To turn the question around a little bit, what workloads is MySQL HeatWave not a fit for? What workloads are going to lead to a poor customer experience where, yeah, this is not a fit for that workload? None, except in terms of the data size. So if you have data sizes which are more than 64 terabytes, then yes, MySQL HeatWave is not a good fit. But if your data size is under 64 terabytes, you're going to win in all the cases by moving to MySQL HeatWave, given the functionality and capabilities of MySQL.

I'd also like to point out that recently, HeatWave gained the MySQL autopilot capability, which I believe is a lot of the machine learning technologies that you were speaking about a few minutes ago. Are there plans to continue to expand what HeatWave does and offer additional functionality? And if you can talk about any of that, I know that roadmap is always something that is difficult to ask about, but it's good you're investing in this. Is your area of investment looking more like it's adding additional features? Is it continuing to improve existing performance? Something else entirely. And of course, we also accept you can't tell me any of that has a valid answer. Well, we just got started. So we just had our first G of heatwave in December. And you saw that earlier this week, we had our second major release of heatwave.

We are just getting started. So absolutely, we are investing a lot in this area. But we're pretty much going to attend to all the things that you said. We have feedback from existing customers, which is very high up on the priority list, right? And some of these are like, you know, just one class of enhancements, which you got is that, hey, can HeatWave handle larger sizes of data? Absolutely. We have done that. We will continue doing that. Second is, can HeatWave accelerate more constructs or more queries? Absolutely, we will do that. And then you have other kinds of capabilities, which customers are asking, which you can think of are like, you know, bigger features,

which you will do. Like, for instance, we announced the support for scale-out data storage, which improves the recovery time. Well, we're going to improve the recovery time, or like we're going to improve the time it takes to restart the database. And when I say improve, we are talking about

not like an improvement of 2x or 3x, but let's say 100 times improvement for, let's say, a 10 terabyte data size. And then we have a very good roadmap, which, I mean, it's a little far out that I can't say too much about it, but we will be adding a lot of very good new capabilities, which will differentiate HeatWave even more compared to the competitive services. You have very clearly forgotten more about databases than most of us are ever going to know. As you've been talking to folks about HeatWave, what do you find is the most common misunderstanding that folks like me tend to come away with when we're discussing the

technology? What is it that is, I guess, a nuance that is often being missed in the industry's perspective as they evaluate the new technology? One aspect is that many times people just think about a service to be some open source code or some on-premise code, which is being hosted as a managed service. Sure, there's a lot of value to having a managed service, don't get me wrong, but when you have innovations, particularly when you have spent years and years or decades of innovation for something

which is optimized for the cloud, you have an architectural advantage which is going to pay dividends to customers for years and years to come. So there is no substitute for that. If you have designed something for the cloud, pay dividends to customers for years and years to come. So there is no substitute for that. If you have designed something for the cloud, it is going to do much better,

whether it's in terms of performance, whether it's in terms of scalability, whether it's in terms of cost, right? So that's what people have to realize, that it takes time, it takes investment. But when we start getting the payoff, it's going to be fairly big. And people have to think,

okay, how many technologies or services are there which have made this kind of investment? So what I'm very excited about is MySQL is the most popular database amongst developers in the world. We spend a lot of time, a lot of person years investing over the last decade. And now we are starting to see the dividends. And from what we have seen so far, the response has been terrific. I mean, it's been really, really good response and very, very excited about it. I want to thank you for taking so much time to speak with me today. If people want to learn more, where can they go? Thank you very much for the opportunity.

If they would like to know more, they can go to oracle.com slash heatwave, where we have a lot of details, including a technical brief, including all the details of the performance numbers we talked about, including a link to the GitHub where they can download the scripts and we encourage them to download the scripts, see that they're able to reproduce the results we said, and then try their workloads. And they can find information as to how they can get free credits to try the service for free on their own and make up their mind themselves.

Kicking the tires on something is a good way to form an opinion about it very often. Thank you so much for being so generous with your time. I appreciate it. Thank you. Nipun Agarwal,

Vice President of MySQL HeatWave and Advanced Development at Oracle. 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 hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment formatted as a valid SQL query. 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.