Oracle's default OCPU-to-ECPU conversion over-provisions MySQL HeatWave capacity by 15% to 30%, and the full analytics stack costs 3x to 5x the base Database Service bill

Every remaining OCPU shape on MySQL HeatWave goes unavailable after March 13, 2026, and Oracle's mapping table is the path of least resistance for your cloud team. Take it unmodified and you carry a 15% to 30% capacity premium into a metric that is partly consumption-derived, on top of a HeatWave cluster and ML/GenAI layer that together multiply the base MySQL Database Service cost by 3x to 5x. Right-size at the conversion, or you never get the chance again.

Prepared by Redress Compliance · August 17, 2026 · Oracle advisory. MySQL and OCI renewal and migration engagements, 2024 to 2026.

The first thing to fix internally is the assumption that MySQL HeatWave has a price. It has three, stacked, and they meter on different principles.

Layer one is the base MySQL Database Service compute, billed in ECPU-hours, which Oracle defines on its own pricing page as a combination of total CPU hours used by the MySQL Database and a measure of work done by MySQL Database and HeatWave.

Read that twice: the unit is partly consumption-derived, not a clean provisioned core count, which means your finance team cannot model it as a fixed monthly line from shape size alone.

Layer two is the HeatWave analytics cluster, an optional in-memory accelerator attached to the DB system, billed per node in units of 16 GB memory-hours allocated. Allocated, not queried. A cluster sized for month-end reporting bills identically on a quiet Tuesday.

Layer three is HeatWave ML and HeatWave GenAI, a separate meter again.

Oracle's own field guidance puts the combined effect at 3x to 5x the base MySQL Database Service cost once the analytics cluster and the ML/GenAI layers are switched on, which is the number your business case for consolidating a transactional database and a separate analytics platform must clear.

The legacy OCPU basis matters for one specific reason during evaluation. Oracle's price list states that 1 OCPU equals 2 vCPUs on x86 architectures, so an OCPU rate is exactly double a vCPU rate for the same silicon.

Every HeatWave-versus-Aurora or HeatWave-versus-AlloyDB spreadsheet we have reviewed that compares an Oracle OCPU line against an AWS or GCP vCPU line is wrong by a factor of two before it starts. The ECPU ladder now runs MySQL.8, 16, 32, 64, 96 (768 GB RAM), 128, 192 (1326 GB RAM), and 256.

Treat MySQL.256 as a commercial term rather than a self-service option: Oracle documents limited hardware availability and routes provisioning through your sales representative and Oracle Support, which is leverage you should use rather than a blocker you accept.

HeatWave on AWS is a narrower SKU set entirely, MySQL.2.16GB through MySQL.32.256GB, with HeatWave node shapes at 16 GB and 256 GB only, and Lakehouse supported exclusively on the 256 GB node.

Clusters scale to 512 nodes, but elastic resize is gated on database version 9.1.0 or later with Lakehouse enabled and node counts of 64 or fewer on both sides of the operation, so the flexibility you are being sold applies to a fraction of the ceiling.

There is also a hidden operational cost in aggressive stop/start scheduling. When a HeatWave cluster stops, the data loaded into cluster memory is discarded and reloaded automatically on restart.

The compute saving is real, the reload latency is real, and the second one is usually discovered by the analytics team rather than by finance.

Compression is the better lever: Oracle's own economics work shows each node processing up to 2x more data at constant price-performance, which translates directly into fewer nodes and up to 50% off the cluster line.

Model that before you model schedules, and read it alongside the broader picture in our Oracle MySQL enterprise licensing buyer guide.

Handle the OCPU deprecation as a procurement event with a named owner in sourcing, not as an infrastructure ticket assigned to a cloud engineer with a mapping table.

The timeline is fixed and public: OCPU shapes have been unavailable to users created after September 5, 2024, and existing OCPU shapes become unavailable after March 13, 2026. There is no third option.

Only ECPU shapes are architecture-agnostic, and only ECPU shapes support HeatWave cluster attachment, so every customer with an analytics ambition is moving regardless of the deadline.

That is precisely why the deadline is worth something to you: Oracle has to complete this migration across its installed base, and a customer who slows down to right-size is a customer whose migration completion date becomes negotiable.

The cost of moving fast is measurable. The benchmark from Oracle licensing field practice is that enterprises accepting the default OCPU-to-ECPU mapping without right-sizing over-provision database capacity by 15% to 30%. That premium is not a one-time conversion charge.

It is a new baseline that compounds across every renewal, every commitment true-up, and every HeatWave cluster sized proportionally to the DB system beneath it.

Because ECPU is partly consumption-derived, an oversized shape also widens the band of possible monthly outcomes, which is exactly the forecasting problem your CFO will attribute to you rather than to Oracle.

Run the conversion off 90 days of observed metered ECPU-hours and peak concurrency, not off a translation table Oracle wrote for its own convenience.

Where you sit on legacy OCPU shapes with no ECPU telemetry, extract CPU utilisation and query throughput at the ninety-fifth percentile and size to that, then plan a single documented step up rather than a permanent buffer. Storage stays where it lands, so size that separately and conservatively.

Then take the whole package into a commitment conversation: a forced migration that Oracle initiated is the strongest moment you will have to reset Universal Credits pricing, secure discount protection on HeatWave node rates, and put MySQL.256 capacity commitments in writing.

Once you pass March 13, 2026 on Oracle's default mapping, you are negotiating from a baseline Oracle chose.

Read Oracle's own definition slowly, because it is the whole story: an ECPU per hour is a combination of the total CPU hours used by MySQL Database and a measure of work done by MySQL Database and HeatWave. That second clause is not a footnote.

It converts the billing unit from something you provision and therefore control into something partly derived from runtime behavior you can only influence.

Twenty-five years of Oracle metric changes have taught the same lesson each time: when the vendor redefines the unit rather than the rate, the rate card stops being the negotiation. The unit is.

The structural consequence is a one-way transfer of forecast risk. Under an OCPU shape, your budget error band was bounded by the shape you chose. You could be wrong about performance, but you could not be wrong about the invoice.

Under a blended metric, workload growth, badly written queries, a new BI dashboard refreshing every five minutes, and a developer who leaves an analytics job in a loop all become billable events rather than performance problems.

Meanwhile Oracle's revenue floor is untouched, because shapes still carry minimum allocations (the ECPU ladder starts at MySQL.8 and runs to MySQL.256, and HeatWave capacity meters in allocated 16 GB memory blocks regardless of query volume). You absorb the upside variance. Oracle keeps the floor.

The sequencing was deliberate, and it deserves to be named. Oracle introduced ECPUs on HeatWave on AWS first, per its own ECPU FAQ, where the installed base was smallest and the political cost of complaint was lowest.

ECPU is now the default across Autonomous Database, Exadata Database Service, Base Database Service, and MySQL HeatWave. HeatWave was the test bed for a metric that now governs the entire database portfolio.

Anyone treating the March 13, 2026 shape cutover as a MySQL housekeeping item is misreading its scope: the conversion language you accept here is the language you will be handed on Exadata and Autonomous next.

The practical casualty is the classic buyer defense. For two decades the reliable control was to cap the shape: pick MySQL.16 rather than MySQL.32 and the ceiling is arithmetic. Capping the shape now caps only one input to the meter.

Worse, the HeatWave layer inverts the intuition entirely, because capacity bills on allocated memory blocks rather than queries executed. Idle analytics capacity is fully chargeable.

A HeatWave cluster sized for month-end consolidation reporting bills identically on the eleven quiet days that follow. There is no query-volume discount for silence, and there is no shape number that makes the memory blocks stop metering while they are allocated.

This is where the 3x to 5x multiplier stops being trivia and becomes a business-case problem. Oracle's field positioning for HeatWave is consolidation: retire the separate analytics platform, keep one system.

The advisory benchmark we work from puts a HeatWave deployment designed to replace both a transactional database and a separate analytics platform at three to five times base MySQL Database Service cost once the HeatWave cluster and the ML/GenAI layers land.

If your replacement case was modeled against the base Database Service line, you have compared the incumbent analytics stack against roughly a fifth to a third of the real Oracle number.

Every consolidation case must be built against the full three-layer stack, including Lakehouse storage, or it is not a case at all. Our Oracle MySQL enterprise licensing buyer guide covers how the same layering logic shows up on the on-premises subscription side.

The negotiation implication follows directly, and it is narrower than most teams want to hear. You cannot architect away a meter that includes work done. What remains are two categories of durable control, and both have to be secured now.

Architectural: compression, which per Oracle's own economics analysis lets a node process up to twice the data and can cut node count roughly in half at constant price-performance; disciplined node counts; and tight Lakehouse scoping so external tables are not silently expanding the storage meter.

Contractual: multi-year rate protection on the ECPU and HeatWave capacity SKUs, written commit flexibility that allows reallocation between layers, and an explicit clause that any future metric redefinition cannot increase your unit consumption for identical workload.

That last clause is the one Oracle will resist hardest, which tells you precisely how much it is worth.

Every FinOps sprint we review reaches for the same reflex: schedule the clusters down overnight and on weekends.

On HeatWave that reflex recovers less than the spreadsheet claims, because five of the seven meters below either keep running while things are stopped or ratchet the floor permanently upward. The table lists the default, what it actually does to the invoice, and the specific control action.

Treat the last column as a provisioning standard, not a suggestion.

The evidence base here is Oracle MySQL and OCI engagements run between 2024 and 2026, cross-checked against Oracle's own MySQL HeatWave Service Guide, the billing chapter (February 2026 revision), the HeatWave release notes, and the shape deprecation guidance published in November 2025.

Two things hold consistently.

First, the 15% to 30% over-provisioning figure on default OCPU-to-ECPU mapping is not a modeling artifact, it shows up because the mapping table converts a provisioned core count into a metric that Oracle itself defines as CPU hours plus a measure of work done.

And nobody re-measures the workload on the way through.

Second, and this is the gap you must close yourself: Oracle renders the HeatWave price tables dynamically, so there is no static rate card to attach to a business case.

The ECPU per hour rate, the HeatWave capacity unit per hour rate (billed in 16 GB memory hour blocks), and the high-availability multiplier all have to be pulled from oracle.com/mysql/pricing on the day you build the model and written into the order document.

On HA specifically, the arithmetic is unforgiving: an HA DB system runs three MySQL instances, so your compute base triples before HeatWave nodes are even attached.

We have seen consolidation cases approved against a single-instance MDS line and then land at 3x on the first invoice for that reason alone.

The repeating patterns are narrow and predictable. Teams size from the shape ladder (MySQL.8, 16, 32, 64, 96, 128, 192, 256) rather than from 90 days of metered hours, which guarantees they land on the shape above their actual need.

Dev and test fleets sit stopped, believing they cost nothing, while storage and retained backups meter on. Lakehouse gets enabled for a proof of concept and never disabled, and per Oracle's billing documentation that storage meter keeps running even when the cluster is stopped.

MySQL.256 requests get routed to Oracle Support as a provisioning ticket when limited hardware availability makes it a commercial conversation with sales. And storage moves one way only, minimum 50 GB, maximum 128 TB, increase only, so an early over-allocation is permanent.

If you also hold MySQL Enterprise subscriptions on premises, read the Oracle MySQL Enterprise licensing buyer guide before you let anyone frame HeatWave as a like-for-like replacement.

The commercial consequence is that your leverage is concentrated in a window that closes on March 13, 2026. After that, the ECPU baseline is whatever your team converted to, and every subsequent negotiation starts from an inflated floor.

Related advisory: the full topic guide.

What is an ECPU in MySQL HeatWave and how is it different from an OCPU?

Oracle defines an ECPU per hour as a combination of the total CPU hours used by MySQL Database and a measure of work done by MySQL Database and HeatWave, so it is a blended metric rather than a pure core count.

An OCPU, by contrast, is a physical core, and because most architectures including x86 run two threads per core, 1 OCPU equals 2 vCPUs and the OCPU hourly rate is twice the vCPU rate. The practical consequence is that ECPU spend has a consumption component you cannot cap by choosing a smaller shape.

Build forecasts from metered hours, not from shape sizes.

When do MySQL HeatWave OCPU shapes stop working?

OCPU shapes have been unavailable to new users created after September 5, 2024, and existing OCPU shapes become unavailable after March 13, 2026. Only ECPU shapes are architecture-agnostic and support attaching a HeatWave cluster, so there is no path that keeps a legacy shape and adds analytics.

Treat the date as a procurement deadline, not an infrastructure one, because it is the last moment you can re-baseline sizing before the new configuration becomes the permanent floor.

How much does HeatWave analytics add on top of MySQL Database Service?

The HeatWave cluster is a separate optional add-on charged per node, billed in 16 gigabyte memory-hour units of allocated memory rather than by query volume, and HeatWave ML and HeatWave GenAI form a third chargeable layer above that.

A deployment designed to replace both a transactional database and a separate analytics platform can run 3x to 5x the base MySQL Database Service cost once all layers are stacked. Any consolidation business case costed against the base line alone will understate the run rate by a multiple.

Does stopping a HeatWave cluster stop the bill?

Partly. Stopping the HeatWave cluster stops billing for the cluster and resumes it on restart, and stopping the DB system stops billing for all compute associated with it, but storage billing continues throughout.

Critically, Lakehouse storage billing continues even while the HeatWave cluster is stopped, and stops only when Lakehouse is disabled or the cluster is deleted. Stopping also discards data loaded in cluster memory, so every restart triggers an automatic reload with a latency and cost penalty.

Can I reduce MySQL HeatWave storage once I have expanded it?

No. Storage runs from a 50 GB minimum to a 131,072 GB (128 TB) maximum and can only be increased, never decreased. Oracle's own documentation warns that billing rises whenever storage size is expanded and advises setting a maximum storage size to prevent cost overrun.

Because Health Monitor auto-expansion is the recommended default and predicts shortfalls from disk usage trends, an accepted default can permanently raise your storage floor without an explicit purchase decision.

Why did my dev and test environments keep billing after teardown?

The default value of AutomaticBackupRetention changed from DELETE to RETAIN, so every new DB system created through the SDK, CLI or Terraform after that release date retains its backups by default.

Ephemeral fleets that are created and destroyed on a schedule therefore leave paid backup residue behind on every cycle. Audit your Terraform modules and set the value explicitly rather than relying on the provider default.

How do I get the MySQL.256 shape, and why does it matter commercially?

Oracle documents limited hardware availability for the MySQL.256 shape and directs customers to their Oracle sales representative, with provisioning assistance via Oracle Support.

That makes large-shape capacity a commercial term rather than a self-service option, so raise it during contract negotiation while you still have leverage, not as a support ticket after you have committed.

Ask for a written capacity commitment by region and a remedy if the shape cannot be provisioned when required.