The rack is in your building. The control plane is not.
Oracle Cloud at Customer is a family of Oracle owned, Oracle operated racks that sit inside your data center and bill as a cloud service. The interesting part is not the hardware. It is the service boundary, what still has to leave your building for the rack to work at all, and who is on the hook at 3am. Most decisions get made on a slide that says cloud economics, your data center. That slide is accurate and almost useless.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on roughly 18 to 24 Cloud at Customer cost models and 15 to 25 hybrid engagements run 2024 to 2025.
Executive summary
It is four products under one brand, and buyers who evaluate it as one decision get sized for the wrong one.
Exadata Cloud at Customer gives you Oracle Database services and nothing else, so your application tier still needs a home; Autonomous Database on the same rack hands Oracle database operations too; Compute Cloud at Customer fills the application gap with general purpose OCI compute.
And a full Dedicated Region gives the wide OCI catalog against a proportionally wider commitment.
They share a delivery model, Oracle owns the hardware and operates it remotely, and very little else: no shared service catalog, control plane design, minimum commitment, or operating model.
The rack is local, but the service that operates it is not, and that has sunk residency business cases at the second legal review.
Every current generation calls back to a linked OCI region for provisioning, scaling, patching orchestration and console visibility, and when that link drops, running databases keep serving while everything else stops.
Your data stays on the rack unless you send it somewhere; your operational metadata, diagnostics, performance telemetry and support artefacts travel to Oracle by design.
If the driver is a regulator rather than latency, get the telemetry scope documented in the order, and check whether your backup target is local storage or Object Storage in the linked region, because the second quietly relocates your data.
You get root on the guest virtual machines and nothing below them, and that lands on your security team, not your database team.
The hypervisor on the physical database servers, the storage servers, the flash tier and the internal fabric are Oracle managed and not customer addressable, so endpoint agents, configuration management, vulnerability scanners and log shippers can only reach the guest VMs.
If your security standard says every host runs the agent, that standard now has a documented exception covering roughly two thirds of the physical stack, and it needs approving before the rack ships, not after your first internal audit finds it.
Managed cloud does not mean managed database patching: on Exadata Cloud at Customer you still plan, test and apply quarterly database patches.
There are two bills, not one, and unreviewed online scaling ran spend 20 to 40 percent over forecast in half the estates.
A fixed infrastructure subscription pays for the installed rack every month whether a workload touches it or not, and a variable service charge pays for the compute you enable, so scaling database compute to zero leaves the fixed charge intact.
Capacity sized to peak left 25 to 45 percent of the committed footprint idle, and minimums signed at full forecast left 25 to 35 percent idle by year two in half the deals. Neither appears on an invoice as idle.
Both are paid in full every month, which is what makes them so easy to miss in a quarterly cost review.
The four products, and the siblings that get confused with them
| Product | What lands in your room | Service scope | Buy it when |
|---|---|---|---|
| Exadata Cloud at Customer | Exadata rack, Oracle owned | Oracle Database only | Database estate cannot leave the site |
| Autonomous Database on ExaCC | Same rack, different service layer | Autonomous only, Oracle runs the database | You want to give up database administration too |
| Compute Cloud at Customer | A general purpose OCI compute rack | Compute, block storage, networking | Application tier must sit next to the data |
| Dedicated Region | A full OCI region, multiple racks | Broad OCI service catalog, local control plane | You are replacing a data center, not a database |
| Database at Azure, GCP, AWS | Same Exadata hardware in a hyperscaler hall | Same operating shape, different procurement | The workload can sit in a public cloud region |
The honest driver is almost never cost. In the engagements behind this page the trigger was a regulator, a latency constraint, or an Exadata refresh arriving at the same time as a cloud mandate.
Cost cases do exist, but they are usually built after the decision to justify it, so treat that sequence as a warning sign and test the residency claim before you test the spreadsheet.
Three adjacent offers are not Cloud at Customer and mixing them in wastes weeks: Oracle Database at Azure, Google Cloud and AWS put the same Oracle owned Exadata in a hyperscaler hall rather than yours; Oracle Alloy is a partner run cloud, a licensing model not something a typical enterprise buys.
And Roving Edge is ruggedized field hardware.
The platform comparison runs Cloud at Customer against a full Dedicated Region.
The service boundary, layer by layer
- Facility, power, cooling: yours to operate and patch, and Oracle will not install without a passed site survey.
- Rack, storage servers, fabric, hypervisor: Oracle operated and Oracle patched, on Oracle's cadence. No agents, no shell, and reboots are coordinated, not requested.
- Guest operating system: yours, patched with Oracle tooling, and your vulnerability clock still runs on it.
- Grid Infrastructure and database homes: yours. Quarterly database patching remains a project you plan, test and apply; the tooling is better than on premises, the accountability has not moved an inch.
- Databases, schemas, data, licensing position: yours, including backup targets, retention, and proving bring your own license eligibility. Autonomous is the one variant where Oracle takes database operations, and the trade is control: your DBAs lose direct access to configuration they are used to owning, so pilot one real workload before you commit the estate.
The Oracle Cloud at Customer strategy playbook
The service boundary, the meter, and the sizing discipline worked through a benchmark estate.
Get the white paper →The meter, and the license path you land in
There are two charges, and conflating them is the single most common modelling error we see.
A fixed infrastructure subscription pays for the installed rack every month of the term whether a workload touches it or not, and a variable service charge pays for the compute you enable, both running through Oracle Universal Credits: you commit to a spend over a term and draw it down.
And unused commitment expires without rolling forward.
Exadata Cloud at Customer database services have historically billed per OCPU per hour, one OCPU being one physical core with hyperthreading enabled, while Autonomous services have moved to the abstracted ECPU.
So check the current service description for your exact service and generation because the conversion also changes how bring your own license entitlements are consumed, mechanics we work on the OCI cost optimization page.
Then you choose a license path per workload, not once for the estate: bring your own license against a lower service rate, which requires a defensible entitlement baseline and active support on every license you count and carries any wrong baseline forward onto a platform Oracle now meters directly.
Or license included at a higher rate that buys containment of exactly that audit exposure.
Price both paths with Oracle Support Rewards applied and both without, put the four numbers side by side, and you have a fifteen minute exercise that has moved seven figure decisions in our file. The conversion mechanics sit in the bring your own license guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across the Cloud at Customer engagement file, 2024 to 2025
Fredrik Filipsson built roughly 18 to 24 Cloud at Customer cost models and advised 15 to 25 Oracle hybrid and Cloud at Customer engagements across 2024 and 2025, plus 10 to 15 infrastructure negotiations that touched the platform.
Those counts describe the same accounts from different angles, so they are not added together, and the findings measure different things:
Median amount Oracle sized the initial OCPU commitment above measured steady state demand. The median commitment we negotiated back down was 22 percent.
Engagements where the customer had not staffed or trained for the split responsibility model before go live. The first quarterly maintenance window was where they found out.
Day two looks like a shared operations model most teams have never run: you keep a database team, lose infrastructure control, and gain a scheduling dependency on a vendor.
Oracle patches the infrastructure quarterly on a calendar you influence but do not own, so set the maintenance window before go live rather than at the first notification, understand rolling versus non rolling maintenance, and name a deferral owner because unowned deferrals become forced windows.
Scaling is online, which is exactly the problem: compute scales up without downtime from a console call by anyone with permission, and unreviewed online scaling pushed spend 20 to 40 percent over forecast in half the estates, where nobody did anything wrong, each increase was justified.
And none were ever reversed.
Restrict scaling permissions to a named group, require a ticket with an expiry date for every increase, and review enabled compute monthly against consumption.
Capacity expansion, by contrast, is a procurement and logistics event with lead time in months, not a console click, so size the floor to steady state and buy headroom through negotiated expansion at locked signature rates.
Entitlement mapping errors, mostly option packs and processor conversions, inflated Oracle's first proposed sizing by 20 to 40 percent, because bring your own license eligibility was overstated in half the deals when legacy licenses did not map cleanly to the conversion ratio.
The six contract terms, negotiated as one package
- Set the minimum to steady state, not peak: commit at 70 to 80 percent of an honest forecast and cover the upside with expansion at locked rates, because idle capacity is paid in full every month and never appears on an invoice as idle.
- Negotiate a step down right: the right to shrink the committed footprint across the term is worth more than a point or two on the unit rate.
- Lock expansion pricing at signature rates in writing for the full term, so a months long lead time is your only expansion problem, not a repricing.
- Govern scaling from day one: a monthly review gate costs nothing and is the highest return control on this platform.
- Gate operator access and document the telemetry scope: enable Oracle Operator Access Control with a named 2am approver, and get what leaves the building into the order. The Oracle practice runs the position with you.
Frequently asked questions
What is Oracle Cloud at Customer?
It is a family of Oracle owned, Oracle operated racks installed inside your own data center and billed as a cloud service through Universal Credits.
It is four products, not one: Exadata Cloud at Customer for database only, Autonomous Database on the same rack where Oracle also runs the database, Compute Cloud at Customer for general purpose OCI compute, and a full Dedicated Region.
They share a delivery model and very little else, so evaluate the specific one, not the brand.
Does data leave the building with Cloud at Customer?
Customer data stays on the rack unless you send it somewhere, but operational metadata, diagnostics, performance telemetry and support artefacts travel to Oracle by design, and the control plane lives in a linked OCI region.
If your driver is a regulator, document the telemetry scope in the order and check whether your backup target is local storage or Object Storage in the linked region, because the second option quietly relocates your data off site.
Who patches what on Exadata Cloud at Customer?
Oracle patches the infrastructure, the rack, storage servers, fabric and hypervisor, on a quarterly cadence you influence but do not own. You still patch the guest operating system, Grid Infrastructure and the database homes yourself.
Managed cloud does not mean managed database patching here: quarterly database patching remains a project you plan, test and apply. Autonomous Database on the rack is the one variant where Oracle also takes database operations.
How does Cloud at Customer billing work?
There are two charges. A fixed infrastructure subscription pays for the installed rack every month of the term whether a workload runs on it or not, and a variable service charge pays for the compute you enable.
Scaling database compute to zero reduces the variable charge and leaves the fixed one intact, which is why sizing to real demand beats sizing to peak by a wider margin here than in public cloud. The rack is installed once; the subscription is paid every month.
Should you choose bring your own license or license included?
Choose per workload, not once for the estate. Bring your own license carries a lower service rate but requires a defensible entitlement baseline and active support on every license, and a wrong baseline follows you onto a platform Oracle now meters directly.
License included costs more and buys containment of that audit exposure. Price both paths with Oracle Support Rewards applied and both without, then compare the four numbers.
Why did Cloud at Customer spend run over forecast?
Because scaling is online and capacity sizing is not reviewed. Unreviewed online OCPU scaling pushed actual spend 20 to 40 percent above forecast in roughly half the estates we reviewed, with each individual increase justified and none ever reversed.
Separately, capacity sized to peak left 25 to 45 percent of the committed footprint idle, paid in full every month. Restrict scaling permissions, require a ticket per increase, and review enabled compute monthly.
