What are you actually paying for with HeatWave?
HeatWave is MySQL with an in memory analytics cluster attached, so a single system serves both transactions and analytics. The bill has two parts. The MySQL database node serves the transactional workload and is sized like any database node by compute and storage. The HeatWave analytics cluster is the in memory engine that accelerates analytic queries, and it is charged by the number of nodes you provision, because each node holds a slice of the data in memory. The analytics cluster bills while it runs, so its node count is the lever that decides whether HeatWave is economical or expensive.
When do the HeatWave economics actually work?
HeatWave saves money through consolidation, not by being cheap per node. The case is strongest when it lets you retire something. If you currently run a transactional MySQL database and a separate analytics warehouse, with a pipeline copying data between them, HeatWave can collapse that into one system: analytics run in place on the same data, the separate warehouse goes away, and the data movement and its cost go with it. If you simply add HeatWave alongside everything you already run without retiring the warehouse, you have added cost, not saved it. So the first question is not what HeatWave costs but what it replaces. The economics are a consolidation argument, and they only hold if the consolidation actually happens.
Where does HeatWave spend go wrong?
The table sets out the common ways HeatWave cost disappoints and the discipline that fixes each.
| Pitfall | What happens | The fix |
|---|---|---|
| Cluster sized to peak | Analytics nodes provisioned for an occasional heavy query bill continuously | Size to the data the cluster must hold, use autopilot to inform node count |
| Nothing retired | HeatWave added alongside an existing warehouse, doubling cost | Consolidate analytics onto HeatWave and retire the separate warehouse |
| Cluster left running | The analytics cluster bills while idle between analytic workloads | Run the cluster when analytics need it and stop it when they do not |
| License mismatch | License included paid where BYOL would be cheaper, or the reverse | Choose license included or BYOL on the real license position |
| Oversized database node | The base MySQL node sized above transactional need | Right size the database node to the transactional workload |
Most disappointment traces to one of two errors: an analytics cluster sized to peak rather than to data, or HeatWave bolted on without retiring the system it was meant to replace.
How do license choices change the math?
OCI lets you run database workloads as license included, where the licence cost is bundled into the service rate, or as bring your own licence, where you apply licences you already hold. If you hold unused or transferable database licences, BYOL can lower the effective rate because you are not paying again for licensing baked into the service. If you do not, license included avoids a separate licence purchase and is simpler. The choice is a real number, not a default, and it interacts with Support Rewards, which offset Oracle support fees in proportion to OCI usage. Net the licence position and the support offset together to see the true cost. The licence decision is covered in depth in the license included versus BYOL article linked below.
A worked example: consolidate and size to data
A European SaaS company ran transactional MySQL on OCI plus a separate analytics warehouse, with a nightly pipeline copying data into the warehouse and an analytics cluster on the warehouse side sized for a rare heavy report. We modelled moving analytics onto HeatWave, sized the analytics cluster to the working data set informed by autopilot rather than to the peak report, retired the separate warehouse and its pipeline, and chose the licence model on the real licence position netted against Support Rewards. Consolidation removed the warehouse and the data movement, and sizing to data rather than peak kept the cluster node count honest. Figures are verified against billing data and anonymized.
How do you keep HeatWave economical over time?
HeatWave stays economical when the cluster tracks the data and the consolidation case keeps holding. Review the analytics cluster node count against the data it actually holds on a regular cadence, and shrink it if the data set is smaller than provisioned. Stop the analytics cluster when no analytic workload needs it if the usage pattern is intermittent rather than constant. Revisit the licence choice when your licence position changes, and confirm Support Rewards are being applied. HeatWave is one database choice inside the wider OCI estate; the architecture level tradeoffs are in the OCI cost optimization guide linked below.
Ask what HeatWave replaced and how its analytics cluster is sized. If it sits alongside a warehouse you still pay for, or its nodes are sized to a peak query rather than to the data, the economics are not yet working.
Frequently asked questions
How is OCI MySQL HeatWave billed?
Does HeatWave save money versus a separate data warehouse?
How do you size a HeatWave cluster to control cost?
Make the HeatWave economics work for your workload
We model whether HeatWave saves you money by consolidating analytics, size the cluster to the data rather than to peak, and choose license included or BYOL on the real numbers. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.