Oracle Cloud@Customer is a deployment model, not a licensing shortcut. The hardware sits in your own data centre, but the commercial model follows Oracle Cloud Infrastructure (OCI): you consume capacity measured in OCPUs and you either bring existing Database licences (BYOL) or pay a licence-included subscription rate. The licensing questions that matter — which metric applies, what counts as a licensable processor, and how options are charged — do not disappear because the box is on-premises. They change shape. This guide is written for the buyer who has to defend the position later, and it sits within our wider Oracle licensing guide.
The family has three members that are routinely confused. Exadata Cloud@Customer (ExaCC) is the Exadata platform delivered as a managed cloud service inside your facility. Dedicated Region Cloud@Customer (DRCC) is a full OCI region — compute, storage and a broad catalogue of OCI services — installed on your premises. Standard Cloud@Customer historically referred to earlier-generation racks. Each is a managed service: Oracle operates the infrastructure, and you consume it on cloud metrics.
How capacity and licensing are measured
On ExaCC, the licensable unit is the OCPU (Oracle CPU), which you scale up and down on the database servers. Crucially, you license the Database for the OCPUs you have enabled, not the full physical core count of the rack. That is the single most important commercial lever on the platform: disciplined OCPU scaling directly reduces both the subscription cost and, under BYOL, the number of licences you must hold.
Database options and management packs are licensed to match the enabled OCPUs as well. If you enable an option such as partitioning, advanced security or a management pack on the estate, it must be licensed across the cores where the database runs. Read the Advanced Compression note for an example of how an easily-enabled option becomes a licensing obligation.
BYOL versus licence-included
Two consumption choices exist for the Database tier. Under licence-included, the subscription bundles the Database licence into the hourly OCPU rate — simplest to administer, and sensible where you hold few existing licences. Under Bring Your Own Licence (BYOL), you apply Database licences you already own and pay a lower infrastructure-only rate. BYOL usually wins when you have a substantial owned estate with active support, because you avoid paying twice for entitlements you already maintain.
| Factor | BYOL | Licence-included |
|---|---|---|
| Best when | You hold owned Database licences with active support | You have few or no existing licences |
| You pay for | Infrastructure subscription only | Infrastructure plus bundled Database licence |
| Compliance risk | Must prove sufficient owned entitlements for enabled OCPUs | Lower — entitlement is in the subscription |
| Exit flexibility | Licences remain yours after the term | Entitlement ends with the subscription |
The double-counting trap: some buyers move owned licences to ExaCC under BYOL while continuing to run the same workloads on legacy on-premises servers during migration. Both footprints consume the entitlement. Confirm in writing how Oracle expects you to count licences during the overlap window, and time the decommission so you are never short of entitlement on either side.
Where DRCC differs
DRCC is broader than a database platform. Because it is a complete OCI region on your premises, its commercial model leans on OCI consumption and, frequently, a committed spend arrangement under Universal Credits. If a data-residency or latency mandate is driving you to DRCC, model the database licensing exactly as you would for ExaCC, then layer the wider OCI service consumption on top. We cover the credit mechanics in our Universal Credits guide.
Contract clauses to negotiate
Cloud@Customer contracts blend a hardware-style commitment with cloud-style metering, and the friction lives in the seams. Before signing, get clarity on the minimum committed OCPU floor and whether you can scale below it; the support and patching responsibilities, since Oracle operates the infrastructure; the data-egress and decommission terms at end of term; and the treatment of your BYOL entitlements if you later move workloads off the platform. Price protection on renewal is worth as much as the headline rate — an attractive year-one number means little if the renewal resets to list.
For an engagement on a specific Cloud@Customer or Exadata position, see our Oracle licensing experts service or the Oracle vendor hub. The recurring theme across every Engineered Systems deal we review is the same: the platform is genuinely capable, but the licensing only stays efficient if OCPU scaling, option enablement and the BYOL count are governed deliberately rather than left to default.
ExaCC versus owning Exadata outright
A frequent buyer question is whether to consume Exadata as a Cloud@Customer service or to purchase the Engineered System as a capital asset and license the Database conventionally. The two routes carry different commercial profiles. Owning the hardware converts the spend into a one-time capital purchase plus annual support, and you license the Database to the physical cores you run; the platform is yours to operate, patch and refresh on your own schedule. ExaCC shifts the spend to an operating subscription, hands day-to-day infrastructure operation and patching to Oracle, and lets you scale licensed OCPUs up and down as workloads change. Neither is universally cheaper. The deciding factors are how predictable your capacity demand is, whether you value Oracle-managed operations over in-house control, and how your finance function treats capital versus operating expenditure.
The migration overlap window
The riskiest moment in any Cloud@Customer move is the period when the old platform and the new ExaCC estate run in parallel. During cutover, the same databases may be live on both, and under BYOL both footprints draw on your owned entitlement. Plan the licence position for the overlap explicitly: confirm how many cores or OCPUs you are licensing on each side, agree the treatment in writing, and compress the dual-running window so you are never exposed to a shortfall. The same discipline applies to Database options enabled during migration testing, which can quietly extend entitlement requirements across both environments.
Who patches what
Because Oracle operates the ExaCC infrastructure, the responsibility boundary differs from an owned system. Oracle handles the infrastructure stack and underlying platform maintenance, while you retain responsibility for the database content, application tier and the decision of when to apply database-level updates. Map these responsibilities against your existing operational model before signing, because gaps here surface as unplanned internal effort rather than licence cost.