The BYOL Asymmetry Nobody Prices In: Autonomous AI Database versus Exadata Database Service

Every Oracle Exadata Cloud@Customer project we see runs into the same argument, and it is almost always the same three questions tangled into one.

Where does the platform run? Who operates the database stack? How is the Oracle entitlement paid for?

Cloud@Customer answers the first. Autonomous versus Exadata Database Service answers the second. License Included versus BYOL answers the third. They are independent, and collapsing them into a single "Autonomous or DBaaS?" decision is what produces the bad conclusions below.

Start with the category error

Cloud@Customer is not an alternative to Autonomous Database. It is Oracle-owned, Oracle-managed Exadata infrastructure sitting in your data center, and it hosts both database services — often on the same rack, at the same time:

• ExaDB-C@C — Exadata Database Service on Cloud@Customer. Co-managed. You hold root on the database VMs.
• ADB-C@C — Autonomous AI Database on Exadata Cloud@Customer. Fully managed. No customer OS access.

Both are Database as a Service. Calling one of them "DBaaS" in contrast to the other is a category error, and it is the root of most of the confusion.

The RAC myth

The statement you will hear in the room is: "Autonomous doesn't need RAC licenses, DBaaS mandatorily does."

That is not correct as written. The accurate version:

With License Included, neither service requires you to buy a separate perpetual RAC license — RAC is in the subscription either way. With BYOL, the RAC requirement depends on the service, the topology, and the allocated capacity. On Autonomous it is a capacity threshold. On Exadata Database Service it is a topology question.

Concretely, under BYOL:

• ADB-C@C needs RAC entitlement only once a single Autonomous Database exceeds 16 OCPUs, equivalently 64 ECPUs. Below that line, Enterprise Edition is enough.
• ExaDB-C@C needs RAC entitlement for any database with two or more instances — no threshold, no allowance.
• ExaDB-C@C on a single-VM cluster needs no RAC entitlement at all. Oracle shipped "VM Cluster on a Single VM" specifically so single-instance workloads can run without RAC licences.

If you have been avoiding the OCPU-to-ECPU conversion out of caution, stop. Oracle publishes the threshold in both metrics, and the RAC ratio above it is one processor license per 2 OCPUs or 8 ECPUs.

The number that actually sizes your exposure

One Oracle Database Enterprise Edition processor license covers 8 ECPUs — equivalently 2 OCPUs — on both Autonomous AI Database and Exadata Database Service. Standard Edition 2 covers 16 ECPUs, but is hard-capped at 16 ECPUs per Autonomous instance.

Two consequences people miss:

1. Entitlement is measured against enabled ECPUs across your VM clusters, not against the number of databases. Consolidating 80 databases onto fewer clusters does not by itself reduce what you must own; reducing enabled ECPU does.
2. It includes peak capacity reached during scaling. Autonomous compute auto scaling can consume up to three times the configured ECPU count. Under BYOL, that is a silent over-consumption unless you set an explicit BYOL ECPU limit on every database. We have seen this enabled in demo environments with nobody noticing the license implication.

And now the asymmetry

Here is the part that reverses most people's intuition.

Under BYOL, Autonomous asks you to own Enterprise Edition and essentially nothing else. The co-managed service asks you to own every option you switch on.

So for any estate that leans on Partitioning, Advanced Compression, In-Memory or Multitenant — which is most mature Oracle estates — Autonomous requires materially less owned entitlement than Exadata Database Service for the same workload. The instinct that "the fully managed service must be the expensive one" is exactly backwards in the BYOL case.

Two operational facts that change the architecture

Rolling infrastructure maintenance is not free for single-instance databases. Oracle patches the Exadata infrastructure quarterly, rolling, one database server at a time — and rolling means the VMs on the server being updated are shut down, patched, restarted. A two-node RAC or Autonomous cluster rides through it. A single-node VM cluster does not: its databases stop.

This matters because "single-node VM cluster to avoid RAC licenses" is a popular and legitimate design. It is just not free. You are trading a RAC entitlement for a Data Guard switchover runbook that you must build, test and execute before every maintenance window — and that orchestration is your responsibility, not Oracle's.

Autonomous Data Guard protects the container, not the database. On Cloud@Customer it is configured on the Autonomous Container Database. The unit of switchover and failover is therefore the whole container and every database inside it. Databases with different RPO/RTO targets, different maintenance windows or different criticality must not share one container. Your database-to-container mapping is your disaster-recovery design, and it has to be decided before migration rather than discovered after it.

One more trap: PDBs

Oracle Database 19c Enterprise Edition gives you up to three user PDBs per CDB without the Multitenant option. The fourth needs it — and Oracle does not technically enforce the limit, so creating it simply succeeds and silently creates an exposure.

If you are consolidating a large estate onto a handful of ExaDB container databases, you will cross that line. Either own Multitenant, or set MAX_PDBS=3 as a hard guardrail, or put the consolidation on Autonomous where Multitenant is included.

How to actually decide

Stop presenting licensing as "Autonomous versus DBaaS". Present it as a calculation:

   Service           (ADB-C@C or ExaDB-C@C)
 + Topology          (single-node, RAC, Data Guard, Active Data Guard)
 + Capacity          (enabled ECPU, including auto-scaling peak)
 + Enabled options   (Multitenant, Partitioning, In-Memory, ...)
 + Commercial model  (License Included or BYOL)
 = Required entitlement

And do not forget the standbys. A Data Guard standby is not covered by the ten-day failover allowance — that applies to an unlicensed failover node in a shared-storage cluster, not to a standby holding its own copy of the data. Every standby carries the same entitlement as its primary, and opening it read-only for reporting pulls in Active Data Guard on both sides.

The honest caveat

None of the above is a licensing opinion binding on Oracle. Ratios and inclusion lists live in the Oracle Cloud Service Descriptions and the price list in force on your order date, and Oracle revises them. Treat published figures as the basis for a question, not as the answer: get the conversion ratio, the ECPU threshold, the option inclusion list and the Multitenant treatment confirmed in writing against your own ordering document before you freeze an architecture or retire a license.

The technical evidence will not save you either. Do not try to prove entitlement from V$OPTION, initialization parameters, installed binaries or the number of visible instances — in a cloud service most options are technically present regardless of what you are paying for. The license model recorded on the resource, the signed order and your own support records are the evidence.

---

Solutia s.r.o. designs and migrates Oracle database platforms. If you are sizing a Cloud@Customer BYOL position and want the arithmetic checked before it reaches a purchase order, talk to us (sales@solutia.cz).