If there was one thing that got CTO Larry Ellison audibly excited on last week’s earnings call it was Oracle’s HeatWave software. The MySQL query accelerator is the “physical manifestation of nearly 10 years of deep database engineering techniques, over five dozen patents and demonstrates what real cloud database innovation looks like in 2021” Ellison said. Currently only available on Oracle Cloud Infrastructure (OCI), the company is taking HeatWave multicloud as part of a managed MySQL service with availability on AWS and Azure coming within weeks, he said. Oracle, Ellison added was “going after the Aurora, the Redshift and Snowflake user base…”
Oracle introduced HeatWave in May 2021. It lets users run Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP) workloads directly from MySQL databases. The big idea, in brief: Avoid sometimes torturous ETL procedures to get transactional data into another database for analytics and capture users wanting a single tool for transaction processing and query processing in MySQL -- winning workloads that might otherwise be split across multiple relational database and/or cloud data warehousing products.
HeatWave, in Oracle’s words, “increases MySQL performance by orders of magnitude for analytics and mixed workloads, without any changes to existing applications.” The company boasts stupendous cost savings vs both AWS’s Redshift and Snowflake, claiming it is “18x faster, provides 110x better throughput and is 2.4x cheaper than Aurora [AWS’s managed relational database engine] for OLAP queries resulting in 42x better price performance.” (nb: That’s using the CH-benCHmark. Below Oracle’s punchy visuals showcasing performance, the very small smallprint does note coyly that “benchmark queries are derived from CH benchmark, but results are not comparable to published CH benchmark results since they do not comply with CH specification…”)
HeatWave certainly has been well received by many analysts and indeed customers. As Tony Baer, principal with dbInsight, put it in an analysis published after Oracle’s HeatWave release. “To enter a MySQL DBaaS market that was already pretty crowded, Oracle would have to sharply differentiate itself. Oracle’s new HeatWave engine does just that, turning up the heat on rival cloud MySQL services by not only adding analytics to the mix, but incorporating hardware and software optimisations that significantly accelerate performance…”
Oracle HeatWave goes multicloud.
Offering HeatWave as part of a managed MySQL offering on AWS and Azure is certainly tactically astute.
As DataStax’s Patrick McFadin notes to The Stack: “MySQL still has the largest market share of data right below Oracle DB. Giving users a path to OLAP on the data they already have with cloud economics isn’t a bad idea.
"For the large user base using MySQL, they would need to convert all their data to PostgreSQL to use Snowflake and Aurora. It’s a pretty good opportunity [for Oracle] that puts a moat around their existing business. OCI is not where the most cloud users are so having a competitive product on every cloud is a great idea.”
Its launch comes amid a state of flux in the database world however; a world in which a rise in NoSQL and "NewSQL" managed services fight it out for custom and as CIOs (certainly some of those that we speak with) become somewhat impatient with database sprawl across their enterprises -- despite wanting to give developers the best tools for the job, the sheer heterogeneity of databases underpinning suites of applicaitons is troubling many.
To Matt Yonkovit, Head of Open Source Strategy at Percona, which provides enterprise support for multiple open source databases, HeatWave is best contextualised as part of a rise in this Database-as-a-Service (DBaaS) offerings over the last five years. He told us: “Automated operations and backend administration is compelling in today’s market where a hunger for new technology and applications prioritises infrastructure that is easy to deploy and get started. HeatWave’s specific features and architecture, while it is a unique implementation in itself, is a similar approach and design to other databases and tools in the market. While HeatWave likes to position against Aurora for instance, its architecture has more in common with other databases that prioritise partitioning and parallel processing like TiDB, Yugabyte, Cockroach, or Vitess. While its focus on analytics does put a focus on other databases like Snowflake, the offering is [currently] an Oracle only, paid solution.
“It becomes another migration path and option if you are looking for scaling MySQL” he noted, but added: “It’s important to note that HeatWave is not a full MySQL database. The limitations are numerous. Some are odd – like no recursive CTES, no JSON support, and no virtual generated column support… With HeatWave and with other databases in the space, we see two camps emerging. There are those that are looking to build out massive data sets that are more than 100 terabytes and with high performance and high costs. The other camp is those looking to break their applications into small microservices components with small contained databases. It is similar to the war between big iron versus commodity x86 boxes in the late 90's and early 00's.”
To Franz Aman, the CMO of MariaDB (a relational database made by the original developers of MySQL), asked how much of a threat HeatWave is to AWS's Redshift, to Snowflake, et al, the answer is blunt: “Little to none”.
“Oracle has consistently done too little too late when it comes to embracing the cloud” he tells The Stack: “Embracing other clouds instead of their own proprietary cloud is just one example, but Heatwave is tied to Oracle’s MySQL InnoDB [storage] engine, all data has to go through that bottle neck, hardly a compelling architecture for cloud analytics”.
Relational SQL databases, however, will continue to dominate the industry for three key reasons, he believes.
"1) “SQL is a common standard and skill set. And SQL is very much alive. It is a standard that is evolving and many databases support the new modern SQL additions. Even the NoSQL databases had to add SQL capabilities due to user demand. 2) SQL databases have added many of the features missing that NoSQL startups invented. JSON is now supported broadly. Scaling out using additional nodes used to be a domain of key/value stores and NoSQL databases, now there is distributed SQL delivering similar of better scale. 3) Everyone wants consistent data, transactional integrity (ACID). NoSQL databases have failed miserably to deliver strong consistency, instead they talk about “eventual consistency”, which for many use cases is just not good enough."
SQL is having a major resurgence with developers David Walker, Yugabyte
David Walker, Field CTO, EMEA, Yugabyte, an open source distributed SQL database company, sees -- with HeatWave -- Oracle "leaping aboard the next generation of warehouse architecture. Or at least, attempting to".
As he puts it: "The first thing to be said is that SQL-based data warehouses comfortably survived the arrival of data lakes, despite the decade-long hype of, and investment in, post or ‘NoSQL’ technologies.
"A critical factor that might have tipped the balance was the monolithic nature of SQL databases: historically, your SQL database was only as big as the machine it could run on. That’s not great for cloud topology, where you want lots of cheap, linked commodity boxes. As SQL databases could only scale up to a bigger physical box and cloud databases scale-out to lots of smaller boxes, there was a mismatch. Nonetheless, SQL held on because of existing skills and high-productivity tools. Most high-value enterprise data (albeit maybe not the highest volume data) is still out there in transactional SQL databases; think e-commerce websites with buyers, sellers, transactions, and balances that become aggregates, trends, leader boards, and comparisons in the warehouse. That also helped keep it relevant. Before too long, credible cloud warehouse solutions (like Snowflake) came along to finally crack the scale-out problem," Walker noted to The Stack.
"Maybe the next move will be for Oracle to try and catch up with the new operational cloud SQL databases that cracked the scale-out problem. But, this time for the billions of 24x7 small transaction updates that transaction-based brands rely on, not just for big read-only data warehouse queries. Perhaps it is choosing to use MySQL rather than cannibalise its eponymous database warehouse business. Whatever the long-term impact of HeatWave, in both warehouse and operational databases, SQL is having a major resurgence with developers. It was always a powerful and elegant way to manipulate data, but legacy SQL databases were dragging it back. It’s great to see SQL’s undeniable back-end performance and robustness being recognised once again. Even by Oracle!"
Simon Riggs, Postgres Fellow at EDB agrees that SQL is going nowhere: "It’s the unchallenged interface to data stores available anywhere and as it continues to evolve every few years, is likely to remain so. NoSQL tried to get around that, but the convenience of an implementation independent language for accessing data stores is hard to beat, especially with data analytics applications which can take advantage of the optimisation possibilities it gives. Does Heatwave challenge anyone however? Probably not. For analytics, MySQL is particularly poor, with significant criticisms coming even from their own developers. PostgreSQL’s optimiser is much better and is used as the basis for Redshift and a number of other analytics databases. But that was 15+ years ago and now Postgres has many new features and optimisations, continuing to make it viable as both an operational and an operational analytics datastore. This leaves PostgreSQL as the #1 Operational datastore and Snowflake as the #1 large analytics datastore. Multi-cloud is interesting, but not a compelling enough feature to make up for the lack of other features..."
What are your views on HeatWave and indeed your own DB experiences? Get in touch.
