HeatWave MySQL on OCI: OLTP and Analytics in One Engine

The standard architecture for a MySQL application that needs analytics has not changed in fifteen years: run the transactions in MySQL, extract the data on a schedule, transform it, load it into a warehouse, and point the dashboards at the warehouse. It works, and it costs three systems, one pipeline, and a permanent freshness gap between what the application knows and what the reports say. HeatWave exists to delete that architecture. It attaches an in memory columnar query accelerator directly to managed MySQL on OCI, so the same database that takes the orders also answers the quarterly revenue question, on current data, with no ETL in between. This guide explains how it works, where it genuinely shines, what it costs to run, and where the classic architecture still wins.

HeatWave is one pillar of the broader estate we map in the OCI data platform guide, and it pairs naturally with the lakehouse patterns later in this series.

The problem HeatWave solves

Mixed workloads break databases in a specific way. Transactional queries want rows: fetch this order, update this account. Analytic queries want columns: sum this measure across fifty million rows. A row store engine like InnoDB serves the first beautifully and grinds on the second, which is why the warehouse industry exists. The conventional fix moves the analytic work to a different system, and pays for it in ETL pipelines, data copies, latency, and two operational surfaces. The HeatWave fix keeps one system and adds a second engine inside it.

How the architecture works

A HeatWave deployment is a managed MySQL DB system with a cluster of HeatWave nodes attached. Tables you choose are loaded into the cluster in a compressed, columnar, in memory format, partitioned across nodes so queries scan in parallel. The MySQL optimizer routes automatically: transactional statements run in InnoDB as normal, analytic queries that would benefit are pushed down to the HeatWave cluster, and changes flow from InnoDB to the columnar copy in real time. The application sees one endpoint and one SQL dialect, which is the point. There is no connection string for the warehouse because there is no warehouse.

Scale is horizontal: more data or more concurrency means more HeatWave nodes, and the cluster can be resized or paused without touching the underlying database. Pausing matters commercially, because analytic demand is often office hours shaped, and a paused cluster stops billing for compute.

Autopilot and the operations story

HeatWave ships with Autopilot, machine learning driven automation that handles the chores that normally make columnar accelerators expensive to babysit: it samples your data to recommend cluster size, chooses partitioning and placement, adapts query plans from execution history, and flags tables that no longer earn their memory. On the MySQL side, the DB system is a managed service with automated backups, patching windows, and high availability options. The operational surface is genuinely small for what the system does, though it is not zero, and the sizing judgement, especially memory fit, is where experienced help earns its keep.

HeatWave Lakehouse: the same engine, pointed at object storage

The columnar engine is not limited to data inside MySQL. HeatWave Lakehouse loads and queries files sitting in object storage, Parquet and CSV included, at the same in memory speeds, and can join them with the transactional tables in one query. That extends the single engine argument from the application database out to the data lake, and it changes the economics of keeping high volume history outside the database. We cover that capability properly in HeatWave Lakehouse, and the surrounding storage design in building a lakehouse on OCI.

Sizing and the memory question

HeatWave economics turn on one variable: how much of the data must be resident in cluster memory. Only the tables you load occupy memory, compression typically shrinks them by a meaningful multiple, and history that analytics rarely touches can live in object storage and be reached through the Lakehouse capability instead of holding a permanent seat in RAM. The practical sizing method is therefore subtractive: start from the full candidate set, remove the columns and partitions the analytic queries never read, let Autopilot estimate the compressed footprint, and buy nodes for that number plus growth, not for the raw schema size. Concurrency adds a second axis, since more simultaneous heavy queries want more nodes, but in most estates memory fit decides the cluster and concurrency merely confirms it. The corrective habit is quarterly: Autopilot reports which loaded tables are not earning their memory, and unloading them is a settings change, not a project.

It is also worth knowing that the same cluster runs in database machine learning. HeatWave AutoML trains and scores models on the data where it sits, which will not replace a data science platform, but removes another export pipeline for the common cases of forecasting, classification, and anomaly detection on operational data.

Where HeatWave fits, and where it does not

HeatWave is the obvious answer when a MySQL application needs analytics: operational dashboards, embedded reporting, customer facing metrics, fraud and anomaly checks on live data. It is a strong answer when an organisation wants to retire a small or mid sized warehouse whose only source is MySQL. It is a partial answer when the analytic estate joins many sources, where it competes with warehouse platforms on their home ground; our honest read of that contest is in HeatWave vs Redshift vs BigQuery.

It is the wrong answer when the source data is not in MySQL and never will be, when the working set cannot reasonably fit cluster memory even after compression, or when the organisation's analytics culture is welded to a specific warehouse ecosystem and its tooling. In those cases forcing HeatWave in creates the very sprawl it normally removes. Independent advice means saying that plainly.

A six step adoption framework

Bringing it together

HeatWave collapses the oldest pipeline in application architecture into a single managed service, and for MySQL centred estates it is frequently the highest leverage move on the whole OCI data platform. The judgement calls are memory fit, workload fit, and the discipline to actually retire the stack it replaces. If you want those calls made with experienced eyes, and the resulting service run properly afterwards, our managed services practice operates HeatWave estates day to day, and an assessment will tell you in a week whether your workload is the shape that wins.