Oracle quietly changed the unit it bills you by. The OCPU — one physical core — is being replaced by the ECPU across Autonomous Database, Exadata Database Service, and Base Database Service. The switch is presented as a modernization. In practice it resets every cost model, conversion ratio, and BYOL entitlement you built on the OCPU, and it does so in Oracle's favour unless you re-run the math. Former Oracle insiders explain what changed and how to defend your cloud budget.
Short answer: An OCPU is one physical Oracle CPU core (presented as two vCPUs); an ECPU is an abstracted "Elastic CPU" drawn from a shared core pool. Oracle now meters Autonomous Database, Exadata Database Service, and Base Database Service per ECPU, and its standard guidance maps 1 OCPU to roughly 4 ECPUs — so every existing cost and BYOL model must be re-validated.
An OCPU (Oracle CPU) is one physical processor core with hyper-threading enabled, which surfaces to the operating system as two vCPUs. It was Oracle's billing unit for most OCI compute and database services from the platform's launch. An ECPU (Elastic CPU) is an abstracted compute unit allocated elastically from a shared pool of cores, deliberately decoupled from any single fixed physical core. Where the OCPU promised a dedicated core, the ECPU promises a measured slice of elastic capacity.
The practical difference is the granularity and the floor. An OCPU is a chunky unit: a dedicated core plus its sibling thread. An ECPU is finer, which lets Oracle offer smaller starting configurations and scale in smaller steps. That sounds like a buyer-side win — and for genuinely small workloads it can be — but the unit change is also the mechanism by which Oracle resets every published rate, every conversion ratio, and every entitlement table that customers had memorised under the OCPU. The metric is the contract's foundation; change the metric and you change the deal.
Oracle's stated reason is elasticity: the ECPU model lets Autonomous Database scale compute independently of storage, supports lower entry points, and aligns OCI's metering with the abstracted-capacity model the rest of the cloud market uses. All of that is real. But it is worth applying Oracle's playbook lens — a metric change is also a repricing event, and Oracle has used unit redefinitions before to reset the baseline buyers negotiate against.
When the unit changes, the published per-unit price changes with it, and the year-over-year comparison customers rely on to challenge increases stops being apples-to-apples. An enterprise that negotiated a strong OCPU rate cannot simply point at the old rate at renewal, because the line item now reads in ECPUs. That break in continuity is the most commercially significant feature of the shift, and it is the reason to benchmark the new model independently rather than trust that "smaller units mean lower cost." It is evidence-based modelling, not Oracle's framing, that protects the budget.
Oracle's standard Autonomous Database migration guidance maps 1 OCPU to approximately 4 ECPUs, and it lowered the per-instance minimum from 1 OCPU to 2 ECPUs. So an instance that previously had to start at 1 OCPU can now start at 2 ECPUs — effectively half the prior compute floor — while a workload that ran on, say, 8 OCPUs converts to a nominal 32 ECPUs under the default ratio. The conversion is not a law of physics; it is a default Oracle applies, and the right ratio for your workload is whatever delivers equivalent measured performance, which you should validate against real consumption data.
| Attribute | OCPU | ECPU |
|---|---|---|
| Definition | 1 physical core (2 vCPUs) | Elastic unit from shared core pool |
| Autonomous DB minimum | 1 OCPU | 2 ECPUs |
| Default conversion | 1 OCPU | ≈ 4 ECPUs |
| Scaling granularity | Whole cores | Finer, smaller steps |
| Storage coupling | Often coupled to compute | Decoupled — scale separately |
| Billing status (2026) | Legacy / some compute services | Default for OCI database services |
The default-ratio trap: Oracle's conversion tooling applies the 1:4 mapping mechanically. If your OCPU instance was already over-provisioned — and most are, because OCPU's whole-core granularity forced rounding up — the 1:4 conversion preserves that waste and bills you for it in ECPUs. Right-size before you convert, not after.
Per unit, an ECPU is priced at roughly a quarter of an OCPU, which is exactly what you would expect when four ECPUs replace one OCPU. The headline number is therefore not the question — the conversion ratio and the new minimums are. For a genuinely small Autonomous Database, the lower 2-ECPU floor can cut cost below the old 1-OCPU minimum, because you are buying half the compute. For a large, already-right-sized estate, the cost should be broadly neutral if the ratio is honest.
Where enterprises lose money is the conversion itself. The 1:4 default carries forward any existing over-provisioning, and Oracle's migration proposals tend to size for peak rather than typical load. Our forensic reviews of OCI database estates consistently show that buyers who right-size during the ECPU transition cut effective database compute spend, while buyers who accept the default mapping pay 15–30% more than a right-sized configuration would cost (Oracle Licensing Experts benchmark, 2026). The metric change is cost-neutral in theory and cost-positive for Oracle in practice — unless you challenge the sizing.
Our Oracle Cloud Advisory service models your ECPU conversion against real consumption and benchmarks the ratio Oracle proposes — before you sign. See our energy-sector case study: $3.5M saved on OCI migration.
As of 2026, the ECPU is the default billing metric for Autonomous Database (Serverless and Dedicated), Exadata Database Service, Base Database Service, and MySQL HeatWave. The OCPU still appears on some compute shapes and legacy configurations, which is precisely why a single estate can carry both metrics at once. That mixed state is where billing errors hide: a finance team comparing this quarter's database invoice to last year's may be comparing ECPUs to OCPUs without realising the unit changed underneath them.
This is closely related to the broader move toward ECPU on Exadata specifically, which we cover in our ECPU vs OCPU on Exadata analysis, and to the way credits are drawn down across services in the OCI Universal Credits model. For Autonomous specifically, the licensing detail sits in our Autonomous Database licensing guide. Before modelling any OCI database cost, confirm the metric service by service — never assume the whole estate moved at once.
Bring Your Own License (BYOL) lets you apply existing on-premises Oracle Database licenses to OCI to reduce the cloud rate. Under the OCPU model the conversion was expressed in OCPUs — for example, one Database Enterprise Edition Processor license covering a defined OCPU count of a given service tier. Under ECPU, Oracle re-expresses those same entitlements in ECPU terms, so the number on the page changes even when the underlying right has not.
The risk is silent under-coverage. If an enterprise built its compliance position on "X Processor licenses cover Y OCPUs," and the cloud service quietly re-baselines to ECPUs, the entitlement math must be redone or the buyer can drift into a compliance gap without any change in deployment. This is also a back-licence claim vector in a future review: Oracle's own metric change becomes the customer's exposure if the conversion is not documented. Re-validate BYOL coverage at every metric transition, and keep the evidence. Our license optimization team treats every metric change as a trigger to re-baseline entitlement, and the on-premises foundations are set out in the Oracle Database licensing guide.
The discipline is the same one that protects any Oracle cloud commitment: measure first, convert second, negotiate the ratio third. Pull real CPU utilisation for each Autonomous and Exadata workload over a representative window — typically the busiest 90 days — and size to typical sustained load with autoscaling headroom for peaks, rather than provisioning the peak as a permanent floor. The ECPU model's finer granularity and autoscaling support make this genuinely easier than it was under whole-core OCPUs, which is the one part of the shift that favours the buyer.
Then challenge Oracle's proposed conversion. The 1:4 default is a starting point, not a fixed term, and the right number is the one that reproduces your measured performance — frequently less than the default for workloads that were over-provisioned under OCPU. Treat the metric transition as a negotiation event, not an administrative one: it is a natural moment to revisit your Universal Credit commitment, your discount, and your renewal floor at the same time. If you want a buyer-side benchmark before you respond to Oracle, that is exactly what an independent review delivers.
An OCPU (Oracle CPU) equals one physical processor core with hyper-threading enabled, presenting as two vCPUs. An ECPU (Elastic CPU) is an abstracted compute unit drawn elastically from a shared pool of cores, with no fixed one-to-one mapping to a physical core. Oracle now bills most OCI database services per ECPU instead of per OCPU.
Oracle's standard Autonomous Database migration guidance maps 1 OCPU to roughly 4 ECPUs, and the Autonomous Database minimum dropped from 1 OCPU to 2 ECPUs. The exact ratio depends on the service and workload, so validate sizing against real consumption rather than accepting Oracle's default conversion, which preserves any prior over-provisioning.
Per unit, an ECPU costs roughly a quarter of an OCPU because four ECPUs replace one OCPU. The effective cost depends on the conversion ratio and the new minimums. Small Autonomous instances often cost less under ECPU, while accepting Oracle's default ratio on an over-provisioned estate can raise the bill by 15–30% versus a right-sized configuration.
Oracle has moved Autonomous Database (Serverless and Dedicated), Exadata Database Service, Base Database Service, and MySQL HeatWave to the ECPU metric. OCPU remains on some compute and legacy services, so confirm the billing metric per service before building any cost model — a single estate can carry both units at once.
Yes. Under ECPU, Oracle re-expresses BYOL conversion ratios in ECPU terms, so one Database Enterprise Edition Processor license now covers a defined number of ECPUs rather than OCPUs. Re-validate that your on-premises license estate still covers cloud deployments after a metric change to avoid drifting into a compliance gap.
Oracle is steering new provisioning to ECPU and will eventually retire OCPU for affected services. Move when you can model the conversion against actual consumption and negotiate the ratio — not when Oracle's account team sets the deadline. Right-size first, then convert, so you are not locked into Oracle's default over-provisioned mapping.
ECPU/OCPU updates, Autonomous Database pricing moves, and Universal Credit negotiation tactics for enterprise Oracle cloud stakeholders.
Former Oracle cloud executives benchmark your OCPU-to-ECPU conversion, right-size your estate, and challenge the ratio Oracle proposes — giving you the analysis Oracle's account team doesn't volunteer. Not affiliated with Oracle Corporation.