The decision between Exadata Cloud on OCI, Exadata Cloud@Customer (ExaCC) and Oracle Database@Azure is the most consequential database-platform choice in the modern Oracle estate. All three deploy the same engineered system (X10M generation as of 2026), the same Oracle Database Enterprise Edition stack, and the same RAC + Active Data Guard configuration options. The benchmark numbers converge inside a 3 – 5% band on any standardised IO or transactional test. Where the three diverge is the commercial wrapper — the infrastructure subscription model, the BYOL conversion mechanic, the data-residency posture, and the audit exposure profile under Oracle's LMS playbook.
This piece works the three variants the way an Oracle insider modelling a multi-million-dollar Exadata proposal would work them: hardware and performance baseline first, the licensing arithmetic second, the total cost of ownership model third, and the buyer-side decision framework last. For the broader Exadata licensing context see the Oracle Database licensing master guide. For Oracle Database@Azure specifically, see the multi-cloud Oracle Database playbook.
The hardware baseline — what each Exadata variant actually deploys
Exadata Cloud Service on native OCI
Exadata Cloud Service (ExaCS) on OCI public regions runs the X10M engineered system inside Oracle's public OCI data centres. The customer consumes the database tier through the OCI console, the OCPU or ECPU billing meters apply, and the hardware is operated by Oracle. The customer never sees the physical kit. Available shapes scale from a quarter-rack equivalent (Exadata.X10M-Base) up to a multi-rack X10M configuration. Storage is RoCE-attached NVMe flash with Exadata Smart Scan offload. The configuration is identical across every OCI commercial region.
Exadata Cloud@Customer (ExaCC)
ExaCC deploys the identical X10M engineered system physically inside the customer's own data centre, but the kit remains Oracle property and is operated remotely by Oracle's cloud operations team. The customer pays an infrastructure subscription for the physical rack (a per-rack monthly charge) plus the database compute consumption (OCPU or ECPU). The customer gets the same management plane as ExaCS — OCI console, Oracle-operated patching, the same OCI tooling — combined with the data-residency property of the kit being inside the customer's premises. ExaCC is the architecture of choice for regulated industries (banks, telcos, government) where the data cannot leave the building.
Oracle Database@Azure
Oracle Database@Azure deploys the X10M engineered system physically inside Microsoft Azure regions, operated by Oracle on Azure-supplied power, cooling and network. The customer consumes the database tier through both the OCI console and the Azure portal (the Azure resource provider exposes the database deployment as a first-class Azure resource). The application tier in Azure connects to the database over private intra-region connectivity — no Oracle Interconnect link, no public internet routing, no cross-cloud latency penalty. The deployment is billed against the customer's Universal Credits commitment and consumes Microsoft Azure-side resources where applicable.
Oracle's Exadata sales motion frequently positions the three variants as architecturally distinct decisions when the underlying engineered system is identical. The architecture is identical; the commercial wrapper is the variable. Treat the three as three commercial routes to the same engine, not three different engines. The buyer-side defence is to model the commercial wrapper in isolation from the marketing — the engine is fixed, the price is negotiated.
The Exadata licensing arithmetic — Licence Included vs BYOL across the three variants
Licence Included pricing
All three variants sell in a Licence Included model where the Oracle Database Enterprise Edition licence cost is folded into the per-ECPU-hour rate. The Licence Included rate also covers the underlying Oracle Database options that Exadata requires (Real Application Clusters, Partitioning, Advanced Compression on the storage tier). The Licence Included rate does not cover the discretionary options the customer may activate — Advanced Security (TDE), Active Data Guard, Database Vault, Spatial and Graph, OLAP, In-Memory — those bill as additional consumption when activated against the database. The per-ECPU-hour Licence Included rate at list pricing is broadly comparable across ExaCS and Database@Azure; ExaCC adds the per-rack infrastructure subscription on top of the database compute.
BYOL pricing
The BYOL model lets the customer carry existing on-premise Oracle Database Enterprise Edition Processor or NUP licences forward into the cloud deployment, paying a lower per-ECPU-hour rate that excludes the Oracle Database licence cost. The BYOL conversion mechanic is two on-premise Processor licences cover one OCPU (equivalent to two ECPUs) on Exadata in any of the three variants. For NUP licences, the standard NUP-to-Processor minimum applies — Exadata storage server count and database server core count drive the minimum. The BYOL discount on the per-ECPU-hour rate is typically 50 – 65% depending on the option mix and the commercial position. For the BYOL mechanics across all three variants and across hyperscaler architectures, see multi-cloud Oracle BYOL rules.
The supporting Oracle option licences
The Exadata stack on every variant assumes the customer has licensed the supporting Oracle Database options where the workload uses them. Real Application Clusters is included in the Licence Included rate and bundled in the BYOL conversion for Exadata; Partitioning is included; Advanced Compression on Exadata storage cells is included. The options that are not bundled — Advanced Security, Active Data Guard, Database Vault, Spatial, OLAP, In-Memory — must be either added on the Licence Included rate as additional per-ECPU charges, or supplied through BYOL Processor licences from the customer's existing inventory. The compliance gap that most frequently triggers a back-licence claim on Exadata deployments is using an unlicensed option that was activated for an ad-hoc test and never deactivated.
The pricing benchmark — what each Exadata variant costs at the indicative published rate
The rates above are indicative published list at the time of writing; real enterprise pricing is negotiated against the Universal Credits commitment, the customer's existing on-premise licence inventory, and the broader Oracle commercial relationship. Discount positions on multi-year Universal Credits commitments above the typical Deal Desk threshold are materially better than the published list — the buyer-side benchmark should be the customer's specific commercial position, not the published rate.
The total cost of ownership — beyond the per-ECPU-hour rate
ExaCS TCO drivers
The TCO model on Exadata Cloud Service is dominated by the OCPU consumption rate, the storage volume, the auto-scaling behaviour, and the Universal Credits commitment level. The customer pays for what is consumed against the commitment with no infrastructure subscription. Network egress (covered in our Oracle@Hyperscaler egress economics piece) is the line item most customers under-model. ExaCS has zero on-premise hardware footprint, zero on-site DBA labour beyond application support, and zero physical infrastructure refresh cycle.
ExaCC TCO drivers
The TCO model on ExaCC is dominated by the per-rack infrastructure subscription plus the database compute, plus the customer's on-premise physical footprint costs (power, cooling, floor space, network distribution). The infrastructure subscription on an X10M Base rack is typically $1m – $1.4m annually before database compute. The trade-off is data residency — the data never leaves the customer's premises. For workloads with hard data-sovereignty constraints (financial reporting, healthcare PHI, government classified) the ExaCC TCO is the right number to model because the alternative is not running in cloud at all. For the head-to-head 5-year economics specifically between ExaCC and Database@Azure on identical Exadata hardware with different billing routes and the MACC offset, see the dedicated ExaCC vs Database@Azure comparison. For the alternative on-premise question — ExaCC versus running Oracle on AWS Outposts hardware — the licensing asymmetry is forensic, and we cover it in the Exadata Cloud vs AWS Outposts comparison.
Database@Azure TCO drivers
The TCO model on Database@Azure is dominated by the per-ECPU-hour consumption against the customer's Universal Credits commitment, plus the Microsoft Azure-side resources the application tier consumes (compute, storage, networking inside the Azure region), plus the cross-cloud or hybrid integration costs where the workload extends beyond Azure. The compelling case for Database@Azure is the customer with an existing material Microsoft Azure footprint and a Microsoft commercial commitment (MACC) that can fund part of the consumption. The customer who is OCI-native gets a worse TCO outcome on Database@Azure than on ExaCS. For the full buyer-side decision framework on this destination — including the BYOL reconciliation Oracle LMS expects and the negotiation deal-shape that holds against Oracle's preferred OCI counter — see the Oracle Database@Azure Decision Framework. The worked example of an over-sized ExaCC estate exiting cleanly to Database@Azure under BYOL is documented in the ExaCC to Database@Azure migration case study, where $9.4M of stranded capacity was defended on a 22-week engagement.
Modelling the Exadata variant decision against your specific commercial position?
We deliver the forensic per-ECPU-hour comparison, the BYOL conversion economics, the infrastructure subscription model on ExaCC, the Database@Azure cost overlay against existing MACC commitments, and the buyer-side commercial provisions that cap exposure. Independent of Oracle and Microsoft commercial motions.
Engage Oracle cloud advisory →The performance comparison — what the Exadata benchmarks actually show
Raw IO and Smart Scan performance
The X10M engineered system in every variant delivers the same flash IOPS profile (millions of read IOPS per rack), the same Smart Scan offload throughput, and the same persistent memory tier acceleration. Benchmarks run against the same workload on ExaCS, ExaCC and Database@Azure converge inside a 3 – 5% measurement-noise band. The hardware is identical, the RoCE storage fabric is identical, and the Oracle Database stack is patched to the same release. Buyers should not chase performance differences between the variants — they do not exist at the engine level.
Application-tier latency
Where the three variants differ in real production is the latency between the application tier and the database tier. ExaCS pairs naturally with application tiers running in OCI regions; the intra-region latency is single-digit milliseconds. Database@Azure pairs naturally with application tiers running in Azure regions; intra-region latency is similarly single-digit. ExaCC pairs naturally with application tiers running in the same customer data centre or in a closely connected metro fibre footprint; latency depends on the customer's network topology. The buyer-side decision should map the application-tier locations to the database variant — a Database@Azure deployment serving an application tier running in OCI is an architectural mismatch that wastes the intra-region benefit.
Operational characteristics
ExaCS and Database@Azure are fully Oracle-operated — the customer's DBA team works against the Oracle Database APIs but does not touch the engineered system. ExaCC is similarly Oracle-operated for the engineered system but the customer's facilities team retains responsibility for power, cooling and physical security. The operational delta is smallest between ExaCS and Database@Azure (both pure cloud-operated) and largest between either of those and a self-managed on-premise Exadata deployment (where the customer's DBA team operates the whole stack).
The audit exposure profile — where each Exadata variant lands under LMS scrutiny
ExaCS audit posture
Exadata Cloud Service on OCI carries the lowest audit exposure of the three because Oracle operates the engineered system and reports consumption against the customer's Universal Credits commitment automatically. The remaining audit risk areas are option activation (turning on Advanced Security or Active Data Guard without the supporting BYOL or Licence Included coverage), shadow environments (test databases spun up outside the governed deployment), and BYOL miscounting (the customer brings forward Processor licences that don't match the ECPU consumption profile). The standard ECPU and option metering closes most of the historical Exadata audit findings.
ExaCC audit posture
ExaCC sits in the middle. The engineered system is Oracle-operated and consumption is metered, but the customer's on-premise environment is the boundary of the data sovereignty. LMS audit scope on an ExaCC deployment frequently extends to the surrounding on-premise environments to verify there is no unlicensed Oracle workload outside the ExaCC scope. The compliance gap to defend against is a development database running on an adjacent VMware cluster that LMS treats as part of the audit population.
Database@Azure audit posture
Database@Azure consumption is reported by Oracle through the Universal Credits commitment, like ExaCS. The audit posture is broadly similar to ExaCS — option activation, shadow environments, BYOL counting — with one addition: the Microsoft Azure-side compute may run other Oracle workloads (Oracle Database installed by the customer on standard Azure VMs in the same or adjacent subscription). LMS audit scope can include the Azure subscription population to check for Oracle workloads outside the Database@Azure scope. For audit defence positioning across hyperscaler Oracle deployments see audit risk in Oracle Database@Hyperscaler.
"The Exadata variant decision is a commercial decision dressed up as an architectural one. The engine is identical. The variables are the infrastructure subscription model, the BYOL economics, the data-residency constraints and the audit exposure profile. Buyer-side defence is to pick the variant whose commercial wrapper matches the customer's actual operating reality — not the variant the Oracle account team gets compensated to push hardest."
The buyer-side decision framework
Choose ExaCS when
Choose Exadata Cloud Service on OCI when (1) the application tier is already running in OCI or is being deployed to OCI, (2) the workload uses OCI-native features (Autonomous Database integration, OCI GoldenGate, OCI Object Storage, OCI FastConnect to on-premise), (3) the customer has built an OCI commercial discount position through prior Universal Credits commitments, or (4) the customer's data-residency posture is satisfied by an OCI public region in the target geography. ExaCS is the lowest-TCO variant when the architecture is OCI-native.
Choose ExaCC when
Choose Exadata Cloud@Customer when (1) data sovereignty requires the database to remain physically inside the customer's data centre, (2) latency to existing on-premise application or analytics workloads is operationally significant, (3) the customer's regulatory framework prohibits public-region deployment, or (4) the customer has a strategic on-premise position they intend to maintain for the foreseeable hardware refresh cycle. The infrastructure subscription is the trade-off; the data residency is the benefit.
Choose Database@Azure when
Choose Oracle Database@Azure when (1) the application tier is already Azure-resident and the intra-region latency benefit is material, (2) the customer has an existing Microsoft commercial commitment (MACC) that can absorb part of the Database@Azure consumption, (3) the integration pattern with Azure-native analytics or AI services (Synapse, Power BI, Azure Machine Learning, Azure OpenAI) materially benefits from intra-region connectivity, or (4) the customer's strategic cloud posture is Microsoft-primary and Oracle is the database tier that needs to land alongside the Azure-native estate. Push back on Database@Azure when the architecture is OCI-native — the commercial economics rarely justify the choice.
An anonymised case study — Tier 1 European bank, Exadata variant selection
A Tier 1 European retail bank with €4.2bn of Oracle Database workloads ran an Exadata refresh decision in 2025 covering 12 production Exadata X8M racks reaching end of support. The Oracle account team proposed a Universal Credits commitment funding a full migration to Exadata Cloud Service on OCI Frankfurt and OCI Amsterdam regions. The proposed commitment value was $48m over five years against the published list ECPU rates.
The buyer-side defence reframed the decision against three variants. ExaCS on OCI Frankfurt was modelled at $32m over five years with a negotiated Universal Credits discount of 38% against list. ExaCC at four locations across the European footprint was modelled at $51m over five years (higher because of the infrastructure subscription) but provided the data-residency posture required for the bank's risk-weighted assets and core banking system, which the bank's regulator would not approve for public-region deployment. Database@Azure on the bank's existing MACC commitment was modelled at $44m over five years and provided a path to consolidate the bank's analytics platform on Azure Synapse with the core Oracle database tier in the same region.
The buyer-side recommendation was a split deployment: ExaCC for the regulated core banking workloads (8 racks across the European data centres), Database@Azure for the analytics and reporting workloads (4 deployments in Azure West Europe paired with the bank's existing Synapse footprint), and zero net commitment to ExaCS on OCI public regions. The total commitment landed at $39m over five years, $9m below the Oracle proposal, while improving the data-residency posture and reducing the bank's net Microsoft Azure consumption commitment by $6m through the MACC absorption. Net five-year saving against the Oracle proposal: $15m; net regulatory posture improvement: significant. For the broader Oracle contract negotiation framework see our Oracle contract negotiation service.
Facing an Exadata refresh or a Universal Credits commitment decision — request a confidential briefing.
We deliver the forensic per-variant economic model, the BYOL conversion analysis, the data-residency posture mapping, the Microsoft commercial overlay where Database@Azure is in scope, and the negotiation framework to challenge the Oracle account team proposal. Buyer-side only. Confidential.
Request an Exadata strategy briefing →Independent · Confidential · Not affiliated with Oracle Corporation
The five buyer-side moves on the Exadata variant decision
Move 1 — Treat the variant choice as a commercial decision. The engine is the same X10M across ExaCS, ExaCC and Database@Azure. The variable is the commercial wrapper. Model the wrapper in isolation from the marketing narrative.
Move 2 — Run the BYOL economics before signing. Existing on-premise Processor licences carry forward at a 2-for-1 conversion ratio against ECPUs in every variant. The BYOL economics frequently outperform the Licence Included pricing on workloads where the customer has surplus Processor inventory.
Move 3 — Negotiate the Universal Credits commitment, not the per-ECPU-hour rate. The Oracle account team will negotiate the commitment value, the term, and the discount tier. The published per-ECPU-hour rate is the input to the negotiation, not the output. Benchmark the customer's specific discount position against comparable commitments.
Move 4 — Defend data residency explicitly.