ExaCC vs Database@Azure is the comparison where the Exadata software stack is identical — but the billing route, the MACC offset, and the strategic flexibility decide where the workload should live.

What ExaCC and Database@Azure actually are

Exadata Cloud@Customer (ExaCC) is Oracle-owned Exadata X10M (or earlier-generation) hardware shipped to and installed inside the customer's own datacentre. Oracle operates it as a managed cloud service, performs all hardware maintenance and patching, and bills by the OCPU-hour against OCI Universal Credits. The customer's data never leaves their premises. Support Rewards apply at 25 percent (or 33 percent for ULA customers).

Oracle Database@Azure is Oracle-owned Exadata X10M and Autonomous Database hardware installed physically inside Microsoft Azure datacentres, presented through the Azure portal, billed on the Microsoft invoice. The hardware itself is identical to ExaCC and Exadata Cloud Service in OCI public regions. Latency between Azure VMs and the Oracle Database is sub-millisecond — the database is on-network in the Azure region. Database@Azure spend qualifies as Microsoft Azure Consumption Commitment (MACC) drawdown. Support Rewards apply at the same rate as ExaCC.

The Exadata software stack, the Oracle Database software, the Smart Scan offload, the Hybrid Columnar Compression behaviour, the RoCE storage fabric — all identical between the two platforms. The decision is location, billing route, and operational integration with the surrounding estate.

Commercial models compared

The list-price premium on Database@Azure reflects the Microsoft revenue layer (Azure infrastructure margin) that does not exist on ExaCC. The premium is partially offset by negotiated Microsoft EA discount on the Database@Azure rate (typically 8 to 15 percent off the Database@Azure list for substantial commits), but the gross premium remains in most deals.

Oracle licensing — identical on both

Both ExaCC and Database@Azure run under the same Oracle Authorised Cloud Environment licensing rules. The key facts:

• 2:1 vCPU-to-Processor multiplier. Two OCPUs (or two Database@Azure ECPUs) equal one Oracle Database EE Processor licence under BYOL.
• BYOL or licence-included. Both platforms offer Bring-Your-Own-Licence (use existing Oracle EE licences and pay only for the infrastructure) or licence-included (Oracle Database EE licence baked into the hourly rate, no separate EE licence required).
• Option licences carry over. Partitioning, Advanced Compression, Multitenant, Advanced Security, Diagnostics, Tuning, RAC, GoldenGate — all the conventional option licences apply with the same 2:1 BYOL conversion. If the customer holds option licences on-premise, those licences can be redeployed to either platform.
• Elastic capacity counts only when running. Both ExaCC and Database@Azure let the customer scale OCPUs/ECPUs up and down. Licensing is consumed against the maximum running OCPUs/ECPUs in the licence-counting period, not the maximum installed capacity.

There is no Oracle licensing reason to prefer one platform over the other. The licensing is symmetric. This is unusual for Oracle — and it is intentional. Oracle has built the Database@Azure offering to be commercially neutral on licensing so that the choice falls to operational and commercial fit rather than licence economics.

The MACC offset mechanic

The single most important commercial fact about Database@Azure is the Microsoft Azure Consumption Commitment offset. Customers with an enterprise Azure commit (MACC) have agreed to spend a minimum amount across Azure services over a 1, 3, or 5-year term. Failure to consume the committed amount results in either a penalty payment or loss of the unspent commit at term end. For organisations with large MACC obligations that are not being consumed organically, Database@Azure spend is a way to rescue the MACC.

The offset mechanic works as follows: Database@Azure consumption (the ECPU-hours, storage, and Exadata software) is invoiced through Microsoft on the Azure invoice. That invoice line counts as qualifying spend against the MACC. A customer with a $20M MACC obligation who deploys $5M of Database@Azure over the term has consumed $5M of the MACC — eliminating $5M of shortfall risk.

The economic value of the MACC offset to the buyer is the difference between paying for Oracle Database (which must be paid regardless) and losing the MACC commit (which would otherwise be a sunk cost). If the MACC was going to be paid anyway and not consumed, the marginal cost of Database@Azure is the Oracle premium over ExaCC minus the recovered MACC value. In many cases, Database@Azure becomes the lowest net-cash answer specifically because of the MACC mechanic.

ExaCC has no equivalent. Spend on ExaCC does not draw down against any Microsoft commitment. For organisations with no MACC obligation, the MACC mechanic is irrelevant and ExaCC is structurally cheaper.

Operational model and Azure integration

ExaCC operational model. Oracle operates the platform end-to-end. The customer logs OCI service requests for any operational issue; Oracle field engineers visit the customer's datacentre for hardware service. The customer's DBAs focus on schema, application, query tuning, and the customer-controlled patching window. The Oracle Database itself is fully under customer control once provisioned.

Database@Azure operational model. Oracle operates the database service through the Azure portal. The customer's DBAs see Oracle Database resources alongside Azure VMs, Azure SQL Database, Azure Storage, and the rest of the Azure estate. Service requests can be raised via either Azure Support or My Oracle Support; Oracle and Microsoft have built joint support runbooks. Integration with Azure-native services is the operational advantage: Azure Active Directory authentication, Azure Key Vault for TDE keys, Azure Monitor and Sentinel for logs and alerts, Azure Private Endpoint for network isolation. The Oracle Database becomes a first-class Azure citizen for operational management.

For organisations whose application teams and DBAs are deeply Azure-native, Database@Azure reduces operational friction materially. For organisations whose Oracle estate is largely self-contained and managed by an Oracle-specialist team, ExaCC is operationally cleaner.

Data residency and sovereignty

ExaCC. Data never leaves the customer's premises. For sectors with strict in-country data residency requirements that cannot be met by public cloud (regulated financial services in some jurisdictions, government, defence), ExaCC is the only Oracle-managed option that keeps the data inside the customer's own facility.

Database@Azure. Data sits inside Microsoft Azure datacentres in the elected Azure region. For organisations already comfortable with their data in Azure (because Microsoft 365, Power Platform, or Azure-hosted applications are already there), Database@Azure introduces no new residency boundary. Database@Azure regions match Microsoft Azure regions — at time of writing, Database@Azure is available in multiple Microsoft Azure regions across North America, Europe, Asia-Pacific, and the Middle East.

For regulated workloads where the data residency rule is "in customer-owned facility," ExaCC wins by default. For workloads where the rule is "in country and meeting sovereignty standards," Database@Azure typically meets the requirement if the Azure region itself does.

Worked TCO example: 64-core EE estate

Scenario: A 2,500-employee insurance group has a 64-core Oracle Database EE estate with Partitioning, Advanced Compression, Multitenant, Advanced Security, Diagnostics, Tuning, and RAC One Node. The group has a $25M annual Microsoft Azure spend with a 5-year MACC commitment of $130M. Annual Oracle on-premise support: $760K. Five-year TCO across the two platforms with two MACC scenarios.

The picture flips entirely with the MACC scenario. When MACC is healthy and being consumed organically, ExaCC is the lowest gross cash-out at $5.34M vs $5.64M for Database@Azure — a $300K saving over five years. When MACC is at risk (the customer is on track to under-consume by $2.45M+ at term end), Database@Azure becomes the cheapest net option at $3.19M because the Database@Azure spend rescues the MACC commitment that would otherwise be a sunk loss.

The MACC scenario is unique to Database@Azure. ExaCC has no equivalent mechanic — there is no Oracle-side rescue for under-consumed commits.

The hybrid topology pattern

For most enterprise Oracle estates of scale, the right answer is not all-ExaCC or all-Database@Azure. The right answer is a hybrid topology that:

• Keeps the highest-residency-sensitivity workloads on ExaCC inside the customer's datacentre. Regulatory tier-0 systems where the data residency rule is "customer-owned facility" go on ExaCC.
• Puts the Azure-native application-tier-integrated workloads on Database@Azure. Systems where the application tier is deeply integrated with Azure services (Azure AD, Azure DevOps pipelines, Power BI dashboards) benefit from Database@Azure's sub-millisecond co-location.
• Uses Database@Azure to absorb MACC consumption. If MACC is at risk, sizing Database@Azure deployments to consume the at-risk MACC delivers the largest single commercial benefit.
• Preserves negotiating leverage at every renewal. Having workloads on both platforms means Oracle is competing with itself (between ExaCC and Database@Azure) and Microsoft is competing with Oracle (between Database@Azure and Azure-native alternatives) at every renewal cycle.

We design these topologies for clients with substantial Oracle and Microsoft commits in roughly two-thirds of buyer-side engagements involving Exadata. The all-in-one-platform answer rarely beats the hybrid on either cash-out or strategic flexibility.

Buyer-side negotiation moves

1. Quote ExaCC and Database@Azure in parallel from Oracle. Oracle's account team will reflexively quote one or the other depending on which sales overlay is dominant in the customer relationship. Force both quotes side by side and treat each as the floor for the other.
2. Bring Microsoft into the Database@Azure conversation explicitly. When Database@Azure is on the table, Microsoft's enterprise account team has leverage with Oracle that the customer alone does not. Microsoft will often unlock additional discount on the Database@Azure rate, migration funding, or MACC consumption credit uplifts when the deal is large enough to matter to Microsoft's Oracle-on-Azure attainment.
3. Quantify the MACC offset explicitly in the business case. Treat the MACC drawdown as a real cash benefit, not a notional accounting saving. Boards and CFOs respond to the framing "Database@Azure rescues $X of MACC commitment that would otherwise be a write-off."
4. Negotiate a workload mobility clause. Both platforms run identical Exadata software; the data is portable in principle. Push for contract language that protects the customer's right to migrate workloads between ExaCC and Database@Azure without penalty during the term. Oracle will resist; concessions are achievable for large deals.
5. Lock the Support Rewards rate in writing on both platforms. The 25 percent (or 33 percent for ULA) Support Rewards rate is documented in Oracle's marketing material but should be referenced in the order form for both ExaCC and Database@Azure spend.

FAQ — ExaCC vs Database@Azure

What is the difference between ExaCC and Database@Azure?

Exadata Cloud@Customer (ExaCC) is Oracle-owned Exadata hardware installed inside the customer's own datacentre and operated by Oracle as a managed cloud service, billed through OCI Universal Credits. Oracle Database@Azure is Oracle-owned Exadata and Autonomous Database hardware installed inside Microsoft Azure datacentres, billed through the Azure invoice and qualifying for Microsoft Azure Consumption Commitment (MACC) drawdown. Both run identical Exadata software with identical Oracle licensing terms. The location, billing route, and commercial mechanics differ.

Does Database@Azure qualify for Oracle Support Rewards?

Yes, but with a different mechanic. Database@Azure consumption generates Support Rewards in the same proportion as OCI Exadata Cloud Service: 25 percent of qualifying Database@Azure spend converts to Oracle support credits, or 33 percent for ULA customers. The spend qualifies even though it appears on the Microsoft Azure invoice — Oracle has built the cross-billing reconciliation. ExaCC enjoys the same Support Rewards rate.

Which is cheaper, ExaCC or Database@Azure?

On a like-for-like Exadata shape, Database@Azure list pricing typically carries a 12 to 22 percent premium over ExaCC, reflecting the Microsoft-side cost layer. The break-even moves materially in Database@Azure's favour when the customer has a Microsoft Azure Consumption Commitment that is not being consumed organically — Database@Azure spend draws down against MACC, eliminating MACC shortfall penalty risk. For organisations without a meaningful MACC obligation, ExaCC is cheaper.

Can we move workloads between ExaCC and Database@Azure during the contract?

Yes, with planning. Both platforms run identical Exadata software and identical Oracle Database versions, so logical workload portability is high. Commercially, ExaCC commits and Database@Azure commits are independent agreements (one with Oracle, one with Microsoft) — you cannot reallocate spend across them mid-term. We routinely design hybrid topologies with some workloads on each platform to preserve flexibility and negotiating leverage at renewal.

What about data residency on Database@Azure?

Database@Azure data resides inside the Microsoft Azure region the customer elects. For regulated workloads where the data residency rule is "in country and meeting sovereignty standards," Database@Azure typically meets the requirement if the Azure region itself does. For workloads where the rule is "in customer-owned facility," ExaCC is the only Oracle-managed option that keeps data inside the customer's premises.

Does Database@Azure support GoldenGate replication to other Oracle databases?

Yes. Database@Azure supports GoldenGate replication to and from on-premise Oracle Database, ExaCC, Exadata Cloud Service in OCI, and Oracle Database in any other location. Cross-platform GoldenGate is one of the patterns we recommend for hybrid topologies where some workloads need to live on each platform — see our broader breakdown in the three-way Exadata comparison.

Independence statement: Oracle Licensing Experts is an independent buyer-side advisory firm. Not affiliated with Oracle Corporation. We have no commercial relationship with Microsoft. All numbers above reflect published list pricing and benchmark enterprise negotiated rates as observed in buyer-side engagements.

Related guides