Customers landing Oracle workloads in 2026 face a fork between two superficially similar OCI deployment models: the public-OCI region (Oracle's hyperscale data centres) and Cloud@Customer (an OCI-compatible appliance in the customer's own facility). The marketing positioning is 'same OCI services, choose your location.' The economic and operational reality is more complex. Cloud@Customer runs 30-50 percent more expensive per ECPU-hour, has a partial service catalogue, longer exit timelines, and a materially different audit-defence profile. This article puts the two side by side across eight decision dimensions and gives the workload patterns that legitimately drive Cloud@Customer selection - and those that do not.
Oracle's deal team usually frames the Cloud@Customer vs OCI public region choice as a simple location question: same services, you decide whether they sit in Oracle's data centre or yours. That framing is correct technically but materially incomplete commercially. Cloud@Customer carries roughly 30-50 percent cost premium per ECPU-hour, runs a partial OCI service catalogue (not the full hyperscale OCI set), and locks the customer into a multi-year capacity commitment with high exit fees. None of that is unreasonable - it is the cost of having OCI infrastructure physically in your facility - but it changes the deal economics enough that the choice should be made on workload-specific evidence, not on a generic location preference.
The framework below decomposes the choice across eight decision dimensions. The wider Cloud@Customer architecture sits in the Oracle Dedicated Region Guide; the pricing breakdown is at Cloud@Customer cost; the service catalogue is at Which Oracle software on Cloud@Customer; the broader OCI framework is at Oracle Cloud Licensing Guide.
Per-ECPU-hour rates on equivalent services run materially higher on Cloud@Customer than on OCI public regions. Reference 2026 BYOL rates on Exadata-class compute:
| Service | OCI public region rate (BYOL ECPU/hour) | Cloud@Customer rate (BYOL ECPU/hour) | Premium |
|---|---|---|---|
| Exadata Cloud Service (ExaCS / ExaCC) | $0.0672 | $0.1008 | +50% |
| Autonomous Database Dedicated | $0.336/ECPU | $0.504/ECPU | +50% |
| Compute (Standard VM) | $0.025/OCPU | $0.038/OCPU | +52% |
| Object Storage Standard | $0.0255/GB-month | $0.0255/GB-month | parity |
On top of the per-ECPU premium, Cloud@Customer carries the infrastructure fee ($15K-$62K per month per appliance), the hardware support fee (22 percent of appliance list), and the minimum capacity commitment. Public-OCI carries none of those.
For a workload running 64 ECPUs 24/7, the public-OCI annual BYOL cost is roughly $37K. The ExaCC annual cost on the same workload (BYOL ECPU + infra fee + support) is roughly $508K. The premium is $471K per year - which the customer pays for having the data tier physically in their facility. Whether that premium is justified depends on dimensions 2-7 below.
This is the most legitimate cost-justified Cloud@Customer use case. If the customer has a latency-sensitive application tier that must remain on-premises (regulatory, legacy integration, edge sites, manufacturing OT), placing the Oracle Database tier in public OCI introduces round-trip latency that breaks the application. Cloud@Customer puts the database in the same rack-or-room as the application tier and recovers single-digit-millisecond latencies.
The latency thresholds matter. An OLTP workload on Oracle Database tolerates roughly 0.5-2ms application-to-database round-trip without performance degradation. A batch analytics workload tolerates 10-50ms. A reporting workload tolerates 100-500ms. The customer with all of their workloads in the latency-tolerant zone has no latency justification for Cloud@Customer; the customer with OLTP applications anchored to a specific physical site has a clean justification.
The diagnostic: measure end-to-end latency from the application tier to the candidate OCI public region using a baseline OCI compute instance. If the latency is below 2ms and the application tolerates it, public OCI works. If the latency runs 10-50ms and the application is performance-bound, Cloud@Customer is the right answer. Most enterprise applications fall in the second category for OLTP workloads in regions far from a major OCI region.
We benchmark your workload list against the eight decision dimensions, model the 5-year cost of each path, and produce a deployment-model recommendation for each workload. Fixed-fee, 2-3 weeks. Prevents the most common Oracle cloud mistake: defaulting to Cloud@Customer when public OCI would have been cheaper and equally fit-for-purpose.
Data sovereignty drives the second-largest Cloud@Customer use case after latency. Regulations covering customer data, financial records, healthcare data and defence information often require the data to remain inside a defined jurisdiction (country, region, or specific facility). The classic examples: GDPR Article 44-50 on EU data transfers, US ITAR/EAR for defence-related data, China's Personal Information Protection Law (PIPL), India's Digital Personal Data Protection Act (DPDPA), Saudi Arabia's PDPL.
Public OCI offers regional residency - the customer can pin workloads to a specific Oracle region (Frankfurt for EU, Bahrain for GCC, Mumbai for India). For most sovereignty requirements, regional residency satisfies the regulation. Where it does not - because the regulation requires data to remain in customer-owned facilities (defence, sovereign banking, some national-security workloads) - Cloud@Customer or DRCC is the only OCI option. Public OCI is structurally incompatible.
Be careful with the framing. Sovereignty as a deal driver is sometimes invoked when the actual driver is risk preference, not regulation. The diagnostic: identify the specific regulation, identify the specific data classification, and validate with legal counsel that regional OCI residency does not satisfy it. If regional OCI residency does satisfy the regulation, the cost premium of Cloud@Customer is not justified by sovereignty alone. The DRCC sovereignty article walks the specific regulatory frameworks.
Public OCI runs roughly 100+ named services across compute, storage, database, AI/ML, networking, security, integration and developer tools. Cloud@Customer in 2026 runs a partial subset of that catalogue. The gap varies by Cloud@Customer family:
The customer who wants the full OCI catalogue on-premises only has one option: DRCC. Workloads that depend on services available only in public OCI (e.g., OCI Generative AI Service, OCI Speech, MySQL HeatWave Lakehouse) cannot be served from a smaller Cloud@Customer footprint. The detail is at Which Oracle software on Cloud@Customer.
Both public OCI and Cloud@Customer support BYOL on the same conversion ratios. 1 Oracle Database Enterprise Edition Processor = 4 ECPUs on either platform. The licence pool is portable - the customer can shift BYOL coverage between public-OCI Exadata Cloud Service and Cloud@Customer ExaCC without contract amendment, provided the documentation is clean.
The portability matters when the customer's workload mix changes over time. A workload that starts on Cloud@Customer for latency reasons may move to public OCI when latency tolerance changes (application replatform, edge-site closure, application modernisation). The BYOL coverage moves with the workload at no additional licence cost. The reverse also works.
The portability is one of the few clean wins for the buyer in Oracle's cloud framework. See the broader BYOL mechanics at Multi-Cloud BYOL rules and the audit-defence framework at Database@Hyperscaler audit risk.
The two platforms have meaningfully different audit-defence profiles, and this is rarely surfaced in Oracle's sales positioning.
Public OCI: Oracle controls the entire OCI control plane. LMS can read consumption directly from the OCI metering service. There is no separate LMS scan of the customer's OCI tenancy - the consumption is the licence record. Audit risk is materially lower than on-premises Oracle deployments, provided the BYOL allocation is documented.
Cloud@Customer: Oracle controls the appliance and the OCI control plane, but the appliance sits in the customer's facility. LMS audit rights on the customer's broader Oracle estate (including on-premises licences used as BYOL coverage for the Cloud@Customer ECPUs) remain unchanged. The audit surface is the broader Oracle estate, not the Cloud@Customer tenancy specifically.
The implication: customers with messy on-premises Oracle deployments (VMware sub-cluster questions, indirect access exposure, Java SE deployment gaps) get the same audit risk on Cloud@Customer as on pure on-premises. Public OCI BYOL reduces that risk because the public-OCI consumption itself becomes the licence record. See the broader Oracle Audit Guide for the audit-defence framework.
Exit profiles diverge sharply between the two platforms.
Public OCI: Universal Credits expire annually if unused. The customer can simply stop consuming and walk away at the annual contract boundary, owing only consumed metered usage. No long-term commitment, no termination penalty.
Cloud@Customer: Multi-year minimum capacity commitment (typically 3-7 years). Default exit clauses owe 50-75 percent of remaining MCC value. On a $3M annual MCC, exiting at year-2 of a 5-year contract owes $4.5M-$6.75M in termination fees. Negotiated exit caps reduce this to 25 percent (still $1.5M-$2.25M on the same example).
The customer who is uncertain about long-term Oracle commitment should default to public OCI for that reason alone. The customer who is structurally committed to Oracle for the next 5-10 years can carry the Cloud@Customer exit risk if the latency or sovereignty drivers are real.
The day-2 operational story differs across the two platforms.
Public OCI: Oracle runs the data centre, the hardware, the power, the cooling, the network. The customer manages the tenant configuration. Customer-side operational headcount is minimal - typically 1-2 cloud-platform engineers per 100 workloads.
Cloud@Customer: Oracle runs the appliance software stack remotely. The customer still owns the data centre, the power and cooling, the network connectivity, the physical security, the hardware logistics for site visits, the on-call escalation for facility issues. Customer-side operational headcount is meaningfully higher - typically 2-4 platform engineers plus data-centre operations support per Cloud@Customer site.
The hidden operational cost of Cloud@Customer is often underestimated. A 5-year run-cost analysis that does not account for the additional data-centre and operations overhead will systematically over-favour Cloud@Customer.
Pulling the eight dimensions together, the decision pattern looks like this:
| Workload characteristic | Default choice | Notes |
|---|---|---|
| OLTP with on-premises app tier, regional OCI 30ms+ away | Cloud@Customer (ExaCC or DRCC) | Latency justifies the cost premium |
| OLTP with cloud-native app tier, regional OCI 5ms away | Public OCI (ExaCS) | No latency need, lower cost |
| Data warehouse / batch analytics, latency-tolerant | Public OCI | No latency need; benefits from elasticity |
| Sovereign data with regulator-mandated physical residency | Cloud@Customer (DRCC for full catalogue, ExaCC for DB-only) | Sovereignty justifies the cost; verify regulation |
| Sovereign data where regional OCI residency satisfies regulator | Public OCI in-region | Lower cost; regional residency suffices |
| Workload needing OCI services not on Cloud@Customer (GenAI, HeatWave Lakehouse) | Public OCI | Service catalogue gap |
| Workload uncertain about 5-year Oracle commitment | Public OCI | Exit flexibility favours public OCI |
| Workload with full BYOL coverage, sunk perpetual licences | Either - economics broadly comparable on BYOL ECPU rate | Drive on latency, sovereignty, catalogue |
The pattern: Cloud@Customer is justified by latency, sovereignty or catalogue coverage that DRCC uniquely provides. It is NOT justified by general risk preference, by Oracle relationship strength, or by a desire to stay 'closer to' Oracle. Customers who default to Cloud@Customer for non-specific reasons pay 30-50 percent premium for no operational benefit. The Cloud Advisory service runs this assessment as a fixed-fee engagement. The Oracle Negotiation Guide covers the broader procurement playbook for whichever path is selected.
Per ECPU-hour, yes - typically 30-50 percent higher on equivalent services. Total cost depends on workload mix. A 5-year run-cost analysis should include both per-ECPU consumption and the additional Cloud@Customer fixed costs (infrastructure fee, hardware support, MCC floor, operational overhead). For pure on-prem-anchored OLTP workloads where latency rules out public OCI, the comparison is moot - public OCI is not a real option. For workloads with deployment flexibility, public OCI is structurally cheaper.
Yes. A common 2026 pattern is primary database on Cloud@Customer ExaCC, standby on public-OCI Exadata Cloud Service, with Data Guard or GoldenGate replicating between them. This pattern is supported and the BYOL licence pool covers both platforms simultaneously. See Oracle MAA Across Multi-Cloud for the architectural framework.
No. Public OCI runs on Universal Credits with annual or pay-as-you-go billing. The customer can commit to an Annual Universal Credits term for discount pricing, but is not obligated to multi-year commitments. The exit flexibility is one of public OCI's main commercial advantages over Cloud@Customer.
Database@Hyperscaler (Azure, AWS, Google Cloud) is a third deployment model that competes with both Cloud@Customer and public-OCI. The Oracle Database service runs on Oracle hardware physically co-located in the hyperscaler's data centre. This positions Database@Hyperscaler between public-OCI (cheaper) and Cloud@Customer (more on-premises). See Database@AWS guide and Database@Google Cloud guide for the detail.
Build the model on per-workload basis, not platform-aggregate. For each workload: pick the platform, sum the 5-year per-ECPU consumption + fixed platform fees (infrastructure, support, MCC if applicable) + customer-side operations cost. The platform with the lower workload-specific 5-year cost wins for that workload. Most enterprises end up with a mixed estate - some workloads on Cloud@Customer for latency or sovereignty, the rest on public OCI for cost flexibility.
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.