Oracle's Exadata Cloud Service - whether running on public OCI (ExaCS), Exadata Cloud@Customer (ExaCC), or Exadata in Dedicated Region (DRCC) - is metered in either Elastic Compute Units (ECPUs) or the legacy Oracle CPU (OCPU) unit. The two are not interchangeable: ECPUs and OCPUs measure different things, price differently, consume BYOL credits differently, and behave differently on workload scaling. The customer who signs an Exadata ordering document without understanding which unit is in use - and which unit they should be in - routinely pays 15-30 percent more than necessary on the term of the contract. This article decodes ECPU vs OCPU mechanics in 2026, the conversion ratios, the BYOL maths, and the negotiation framework for which unit to land on.
Oracle introduced the Elastic Compute Unit (ECPU) on Autonomous Database in 2022 and extended it to Exadata Cloud Service in 2023. The ECPU is the strategic unit going forward - Oracle's product direction is ECPU-based across all Exadata-class services, including ExaCS, ExaCC and DRCC. OCPU remains supported for legacy customers but new deployments default to ECPU.
The two units do not measure the same thing. An OCPU is roughly an Intel hyper-threaded physical core (2 vCPUs). An ECPU is one virtual CPU thread (roughly half an OCPU in compute throughput). The 2:1 conversion ratio is fixed and well-documented, but the implications - particularly on BYOL coverage, sizing, scaling and cost - are not always obvious.
The customer who is negotiating a new Exadata contract in 2026 must understand which unit is in use. The customer who already runs an Exadata service on OCPU should evaluate whether ECPU migration improves the cost structure. The customer who is sizing a fresh deployment should start from ECPU because Oracle's future product roadmap is ECPU-centric.
The wider Exadata architecture sits in the Oracle Database Licensing Guide; the Cloud@Customer perspective is at Cloud@Customer cost; the BYOL framework is at Multi-cloud BYOL rules; the broader cloud framework is at Oracle Cloud Licensing Guide.
The definitions are dense but important.
OCPU (Oracle CPU): One OCPU equals one full physical CPU core with hyper-threading enabled. On Intel x86 platforms, 1 OCPU = 2 hardware threads (vCPUs in OS terms). On Arm platforms (Ampere A1), 1 OCPU = 1 hardware thread because Ampere does not implement SMT. On Exadata X11M (Intel Sapphire Rapids), 1 OCPU = 2 hyper-threads.
ECPU (Elastic Compute Unit): One ECPU equals one CPU thread (one vCPU in OS terms). On Intel-based Exadata, 1 OCPU = 2 ECPUs. On Arm-based platforms, 1 OCPU = 1 ECPU. The ECPU is the finer-grained unit and allows tighter sizing.
For OS-level reporting:
| Compute unit | Linux /proc/cpuinfo entries | Database CPU_COUNT setting |
|---|---|---|
| 1 OCPU on Intel Exadata | 2 entries | CPU_COUNT = 2 |
| 1 ECPU on Intel Exadata | 1 entry | CPU_COUNT = 1 |
| 1 OCPU on Arm A1 | 1 entry | CPU_COUNT = 1 |
| 1 ECPU on Arm A1 | 1 entry | CPU_COUNT = 1 |
The implication for Oracle Database workload sizing: a workload that needs 16 CPU threads (CPU_COUNT = 16) needs 8 OCPUs OR 16 ECPUs on Intel Exadata. The ECPU sizing is more transparent because the number matches the OS-level CPU count directly.
The conversion ratio on Exadata is fixed: 1 OCPU = 2 ECPUs. This applies to:
The OCPU unit on Exadata is essentially legacy. New deployments are ECPU. Migration from OCPU to ECPU on existing ExaCS or ExaCC services is straightforward - the customer requests the conversion via the OCI Console or CLI, the underlying compute and storage are unchanged, only the billing unit changes.
OCPU remains the unit on non-Exadata services: standard VM compute, Compute Cloud@Customer VMs, BM.Standard shapes. The ECPU is an Exadata-specific concept that has not been extended to general OCI compute.
We model your actual workload against ECPU vs OCPU sizing options, validate your BYOL coverage strategy, and identify the cost difference between current and optimal unit selection. Fixed-fee, 2 weeks. Typical recovery on a mis-sized Exadata deployment: 15-30 percent of run-cost.
This is where the two units diverge most consequentially. The Oracle Database BYOL conversion ratios on Exadata:
| Perpetual licence | Covers (OCPU) | Covers (ECPU) |
|---|---|---|
| 1 Oracle Database EE Processor | 2 OCPUs on Exadata | 4 ECPUs on Exadata |
| 1 Oracle Database SE2 Processor | 4 OCPUs on Exadata | 8 ECPUs on Exadata |
| 1 Oracle Database EE NUP (Named User Plus) | 1 NUP per OCPU min (25 per OCPU on Exadata) | 1 NUP per 2 ECPUs min |
The customer with 48 Oracle Database EE Processor licences has BYOL coverage for:
Both numbers represent the same actual compute. The unit choice does not affect the BYOL coverage ratio - it affects only the granularity at which the customer can activate compute.
The advantage of ECPU for BYOL: a customer with 48 Processors who wants to activate exactly enough ECPUs to cover a 100-thread workload can do so (100 ECPUs, leaving 92 ECPUs of headroom). The same customer working in OCPUs would have to activate 50 OCPUs (= 100 threads), and would have only 46 OCPUs of headroom - less elastic for adjusting to actual demand.
Reference 2026 published Oracle rates on the two units across public OCI ExaCS:
| SKU | OCPU rate (legacy) | ECPU rate (current) | Notes |
|---|---|---|---|
| Database EE - hourly | $5.04/OCPU/hour | $2.52/ECPU/hour | 2 ECPUs per OCPU; equivalent on conversion |
| Database EE BYOL - hourly | $1.34/OCPU/hour | $0.67/ECPU/hour | 2 ECPUs per OCPU; equivalent |
| EE + Database In-Memory - hourly | $7.97/OCPU/hour | $3.99/ECPU/hour | Includes options bundle |
| EE + DB In-Memory BYOL - hourly | $2.02/OCPU/hour | $1.01/ECPU/hour | BYOL of EE + each option licence |
| Autonomous Database - hourly | n/a (ECPU only) | $0.336/ECPU/hour BYOL | ADB does not support OCPU |
The headline insight: the per-unit rates differ but the per-equivalent-compute cost is identical. 1 OCPU and 2 ECPUs cost the same. The unit choice does not change the overall consumption cost for the same workload at the same utilisation.
The unit choice DOES matter for elasticity and right-sizing. A workload that needs 5 OCPUs of capacity has no smaller unit to step down to on OCPU - it pays for 5 OCPUs whether it actually uses 4 or 5. On ECPU, the same workload can run at 9 ECPUs (= 4.5 OCPUs equivalent) and pay 10 percent less. Right-sizing to actual demand is finer-grained on ECPU.
The ECPU unit was introduced specifically to enable finer-grained scaling. On Exadata Cloud Service in 2026:
For Autonomous Database on Dedicated Exadata Infrastructure (ADB-Dedicated):
The auto-scaling feature on ADB-Dedicated is ECPU-only. A customer who wants Autonomous Database with auto-scaling between 8 ECPUs and 24 ECPUs cannot get that pattern on OCPU. The OCPU equivalent would require manual scaling between 4 OCPUs and 12 OCPUs with downtime for each scale operation.
The implication: customers running workloads with significant demand variability (typical business-hours/non-business-hours patterns, monthly batch peaks, seasonal traffic) get materially better cost outcomes on ECPU because the unit allows tighter alignment to actual demand.
Oracle's strategic database product on Exadata is Autonomous Database (both ADB-Dedicated and ADB-Serverless). ADB has been ECPU-only since 2022 - OCPU was never an ADB pricing option. Customers planning to deploy Autonomous Database on Exadata Infrastructure must commit to ECPU regardless of what their other Exadata workloads use.
This creates two patterns:
For customers planning Oracle Database 23ai deployment with AI Vector Search, JSON Duality, Select AI, or other 23ai-specific features, ECPU is essentially mandatory because 23ai's primary deployment path on Exadata is via ADB-Dedicated (which is ECPU-only). See the related blog on Oracle 23ai Vector Search licensing.
For new Exadata contracts in 2026, the default negotiation position is ECPU. Reasons:
For existing OCPU-based Exadata contracts, evaluate ECPU migration at the next contract renewal or natural workload migration boundary. The migration itself is straightforward (a configuration change, no data migration); the contractual change requires Oracle approval but is routinely granted.
The only case where OCPU may make sense: customers with substantial sunk OCPU-denominated discount agreements where re-pricing to ECPU would lose discount value. This is rare and deal-specific. Default position: ECPU.
LMS audit of Exadata BYOL deployments is identical across ECPU and OCPU - the audit examines the customer's perpetual licence pool against measured Exadata consumption, and validates that the BYOL coverage ratio (1 Processor = 2 OCPUs or 4 ECPUs) is correctly applied. The unit choice does not change the audit posture.
The compliance discipline that matters:
The wider audit-defence framework is in the Oracle Audit Guide; the Database-specific compliance rules are in the Oracle Database Licensing Guide; the optimisation framework around BYOL and ECPU sizing is in the Licence Optimisation Guide.
No. 1 OCPU equals 2 ECPUs on Intel Exadata. The OCPU is a full physical core with hyper-threading; the ECPU is a single CPU thread (one vCPU). The pricing reflects this: 1 OCPU costs roughly twice what 1 ECPU costs because it provides roughly twice the compute. For workload sizing, an Oracle Database CPU_COUNT of 16 maps to 8 OCPUs OR 16 ECPUs on Intel Exadata.
Yes. The migration is a configuration change - the customer requests the unit conversion via OCI Console or CLI, the underlying compute and storage are unchanged, only the billing unit changes. There is no service downtime and no data migration required. The contract change (if the original contract was OCPU-denominated) requires Oracle approval but is routinely granted at contract renewal or at a workload migration boundary.
Not on a like-for-like compute basis. The cost per equivalent compute (1 OCPU = 2 ECPUs) is identical. ECPU enables cheaper Exadata in two ways: finer-grained sizing (you can size 9 ECPUs instead of having to round up to 10 OCPUs), and access to auto-scaling features on Autonomous Database that are not available on OCPU. The cost benefit comes from better right-sizing and elasticity, not from the unit itself being cheaper.
Yes, at the 1 Processor = 4 ECPUs conversion ratio (same compute as 1 Processor = 2 OCPUs). A customer with 48 perpetual Database EE Processor licences has BYOL coverage for 192 ECPUs of Exadata Cloud Service consumption. The licence allocation can be split across ECPU and OCPU services within the same pool - the underlying compute equivalence determines coverage, not the unit name. See Multi-cloud BYOL rules.
Oracle introduced ECPU specifically to support Autonomous Database's auto-scaling feature, which requires the finer-grained unit. ADB needs to scale between (for example) 8 and 24 ECPUs based on actual demand - that level of granularity is not achievable with OCPU. Once ADB committed to ECPU, Oracle's product roadmap extended ECPU to ExaCS, ExaCC and DRCC for consistency. OCPU remains supported on Exadata for legacy customers but is in maintenance mode.
Twice a month. Oracle cloud, DRCC, ExaCC contract patterns, audit-defence tactics and BYOL maths. Written by former Oracle insiders.
No spam. Unsubscribe any time. Independent - not affiliated with Oracle Corporation.