Announcer: 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.

Corey: You could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is 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 I sent you and watch them wince—because everyone does when you bring up my name. Thats 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?

Corey: 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. It 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 headache for everyone trying manage disparate and fractured cloud environments. VMware has an answer for this. With VMware 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 to take a look at vmware.com/go/multicloud. You know my opinions on multi cloud by now, but there's a lot of stuff in here that works on any cloud. But don’t take it from me thats: VMware.com/go/multicloud and my thanks to them again for sponsoring my ridiculous nonsense.

Corey: 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?

Nipun: That’s absolutely right. 27 years and that was my first job out of school. So, [laugh] yes.

Corey: 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 unearth that you have—what is it now, 170, 180 filed patents that have been issued?

Nipun: That’s right. 180 issued patents. [laugh].

Corey: You clearly know what you’re doing when it comes to databases.

Nipun: Thank you for the opportunity. Yes, thank you.

Corey: So, being a VP at Oracle, but starting off as your first job as 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 in companies for a long time need more examples and role models to look at in that sense, just because it is such an uncommon narrative these days. You’re not bouncing around between four companies.

Nipun: Yeah. I’ve been lucky enough to have joined Oracle, and although I had been at Oracle, I’ve been on multiple teams at Oracle and there has been a great opportunity of talent, colleagues, and projects, where even to this day, I feel that I have a lot more to learn. And there are opportunities within the company to learn and to grow. So no, I’ve had an awesome ride.

Corey: 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?

Nipun: HeatWave is an in-memory query accelerator for MySQL. It accelerates complex, long-running, analytic 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 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 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 worked with MySQL continue to work, except they will be much faster. That’s what HeatWave is.

Corey: 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 fourteen hundred 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 HeatWaves data sizes when it comes to really being able to shine?

Nipun: So, there are two aspects where our customers are going to benefit from HeatWave. One characteristics is the data size, but the other characteristics 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, yes, 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 1400 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.

So, for pure analytics—say, for four terabytes—is 1400 times faster at half the price. So, if it provides truly 800 times better price performance compared to Aurora for pure analytics. Now, let’s take the other extreme. 100 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 TPC-C transactions, and then some added IPP-CH queries, which—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 2800.

Corey: Does this have an upper bound, for example? Like, 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?

Nipun: We designed HeatWave 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 we are seeing, 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.

Corey: 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 now have to store it in two different places instead of one. Plus, in many cases, the vaguearities 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 wind, 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.

Nipun: That’s an excellent point and 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 and one-fifth the cost; 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. 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 to 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 well as 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 HeatWave will perhaps be even higher.

Corey: 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 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?

Nipun: 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. So, we have come up—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; you don’t use, for instance, locally attached SSDs because that will be expensive. Similarly, for compute: instead of using Intel, we use AMD chips because they are 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 quality 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.

Corey: I want to dig into 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 the gathering, 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?

Nipun: So, there are multiple parts to this question. The first thing is—and I think as you’re noting—that with the 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.

Corey: Oh yes, hell is other people’s data centers, for sure.

Nipun: [laugh]. 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, like, specific things which make it very, very compelling. The third thing, I think, which you were 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: what was the compilation time? What was the execution time? And then, based on this data which we’re collecting, we have then come up with very advanced algorithms—machine learning algorithms—which are, again, a lot of them, there is, like, you know, patterns or [IP 00:14:13] 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.

Corey: 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 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?

Nipun: Correct.

Corey: Is there any licensing story tied to that? In other words, “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.

Nipun: So, it’s exactly the letter 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 that is holding you back. The second thing—and I’m glad you brought it up—about the vendor lock-in. 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. So, if customers have the 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. So, the ease of 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 HeatWave.

Corey: There is the counter-argument as far as lock-in goes, and we see this sometimes with companies we talk to that were 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 means that they find themselves de-facto locked in?

Nipun: If you were to talk about some functionality which we are offering which no one else is offering, perhaps you could, kind of, make that case. But that’s not the case for performance because when we are so much faster—so suppose I said, okay, we are so much faster; we are six-and-a-half times faster than Redshift at half the cost. Well, if someone wanted the same performance, they can absolutely do it Redshift on a much larger cluster, and pay a lot more. 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 Spanner; 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 had these proprietary extensions and they feel locked in. That is not the case at all with HeatWave.

Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don’t ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.

Corey: 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 scratched 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 onto GitHub as well. What led to that change? That seems like the least Oracle-like
thing I could possibly imagine.

Nipun: I couldn’t 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.

Corey: That’s one of the baseline building blocks of any environment. I don’t even need to be in the 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.

Nipun: That’s right.

Corey: It is a de-facto standard.

Nipun: That’s right. So, given that is the case and many other 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 a 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.

Corey: I haven’t run 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 we keep waiting for people to come back with, “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, “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’m 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?

Nipun: 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. So, right off the bat, customers save half the cost by moving to MySQL HeatWave.

And then depending upon the workload you have, as you have more complex queries, the performance advantage starts increasing. So, 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 HeatWave. 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 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 are moving data from, say, some open-source databases, if they are ETL-ing 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 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—and it’s a single database for all your applications, significantly reduces the complexity for users.

Corey: To turn the question around a little bit, what sort of workloads is MySQL HeatWave not a fit for? What sort of workloads are going to lead to a poor customer experience? Where, yeah, this is not a fit for that workload?

Nipun: 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.

Corey: 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 clear that 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 [laugh] that has a valid answer.

Nipun: Well, we just got started, so we just had our first [GF 00:27:03] 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 are pretty much going to attempt all the things that you said. We have feedback from existing customers which is very high up on the priority list. And some of these are just one, say, class of enhancements which [unintelligible 00:27:25], 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 for instance, we announced the support for scale-out data storage which improves recovery time. Well, you’re going to improve the recovery time or you’re going to improve the time it takes to restart the database. And when I say improve, we are talking about not an improvement of 2X or 3X, but it’s 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.

Corey: 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?

Nipun: One aspect is that many times, people just think about a service to be here 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 in 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, 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. 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 that okay, how many technologies or services are out there which have made this kind of investment?

So, what I’m really 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, you know, 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 we are very excited about it.

Corey: 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?

Nipun: Thank you very much for the opportunity. If they would like to know more, they can go to oracle.com/heatwavewhere 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.

Corey: [laugh]. 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.

Nipun: Thank you.

Corey: 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’ve 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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.