Oracle Exadata Cloud at Customer or a Dedicated Region. Which problem each one solves, and how each one bills.

Exadata Cloud at Customer is a managed database platform with a fixed rack subscription and elastic compute. A Dedicated Region is a full OCI region bought as one long consumption commitment. Pick by the problem your rule names, not by deal size.

Oracle account teams often present Exadata Cloud at Customer and an OCI Dedicated Region as two sizes of the same idea. They are different products. One is a managed database platform, the other a complete cloud region, and they bill in different shapes.

Choose the wrong one and you spend a four year term paying for the wrong kind of flexibility. Below we compare what each product runs, how each one bills, what late expansion costs, and the contract terms to settle before signature.

What is the difference between Exadata Cloud at Customer and a Dedicated Region?

Exadata Cloud at Customer runs Oracle Database and nothing else. A Dedicated Region runs the wider OCI service catalog under its own control plane. Oracle's Cloud at Customer family has a third member between them, a general purpose compute rack, and most shortlists skip it.

Exadata Database Service on Cloud at Customer

This is a managed Exadata platform installed in your data center and operated by Oracle. You get Exadata storage offload, RAC and Oracle managed patching without owning the machine. The control plane stays in an OCI public region, so your team manages it through the normal OCI console.

• What it is for. Consolidating Oracle Databases that cannot move to a public region.
• What it will not run. Application servers, containers, analytics services, or anything else that is not an Oracle Database.
• Shapes on offer. Oracle's Exadata Cloud at Customer price list shows base system racks, standard racks in several sizes, and expansion racks including Extreme Flash variants. The current generation is listed as X11M, in X11M, X11M-L and X11M-XL rack sizes.

Our Exadata Cloud at Customer licensing guide goes through the platform metric by metric, and the Cloud at Customer licensing guide covers the whole product family.

OCI Dedicated Region

A Dedicated Region is a complete, self contained OCI region that Oracle installs and runs inside your facility. Oracle's Dedicated Region page describes a footprint that starts at three racks and carries more than 200 OCI services, and the FAQ says it scales past 450 racks. Oracle previously sold it as Dedicated Region Cloud@Customer, or DRCC.

Oracle's Dedicated Region FAQ states that the region is not connected to Oracle's commercial public regions and cannot be run from the same console. The same FAQ says pricing is intended to match the commercial public regions.

• What it is for. Keeping a whole IT environment in country: compute, storage, networking, analytics, developer services and identity, all behind your perimeter.
• What comes with it. Its own console and tenancy, separate from any public region tenancy you already run.
• What it costs beyond money. A building project, with site planning for power, space and networking before the first rack arrives. Oracle says the region can be in use within months once the data center is ready. We cover the site prerequisites in the Dedicated Region guide.

Compute Cloud at Customer, the option most shortlists leave out

Oracle also sells Compute Cloud at Customer, a single rack platform that delivers OCI compute, storage and networking locally, without the database machine or the region. It attaches to your OCI tenancy, which handles identity and billing, while day to day resources run from its own local console.

Oracle documents a direct connection to Exadata Cloud at Customer, so application servers can sit next to your databases. If a handful of applications must run on local cloud infrastructure and your databases are already handled, this is usually the cheapest way to meet the requirement. Ask for it by name, because account teams rarely put it on the table.

The two headline options side by side

Which problem does each platform solve?

Exadata Cloud at Customer solves a database problem. A Dedicated Region solves a problem that covers the whole environment and its control plane. Almost every poor selection we have reviewed came from answering the second question with the first budget, or the reverse.

When is it a database problem?

Most Exadata Cloud at Customer deals start because an on premises Exadata is approaching refresh and the data cannot move. The buyer is not choosing cloud. The choice is between another capital refresh and a subscription that behaves much like one.

Frame the negotiation that way. You are comparing a four year infrastructure subscription against a hardware purchase plus support, and a fair comparison leaves the migration cost out of both sides.

When does the rule cover the whole environment?

A Dedicated Region is bought when a rule covers every workload and the systems that run them. Sovereign cloud mandates, defense programs and central bank supervision produce this shape, because they attach to the control plane and the operator.

Read the rule itself before anyone sizes hardware. If it names only the data, a database platform usually satisfies it. If it names the operator, the jurisdiction or the physical media, you are looking at a region.

How does each platform bill?

Exadata Cloud at Customer bills in two parts: a fixed infrastructure subscription and elastic database compute. A Dedicated Region bills as a single consumption commitment that everything draws against. That structural difference decides more deals than the headline numbers do.

The two lines on an Exadata Cloud at Customer invoice

Oracle's published price list separates the infrastructure from the database compute, and the two behave in opposite ways.

• Infrastructure subscription. The rack, priced per month, which Oracle requires on a four year term. This line is fixed and does not move with usage.
• Database compute. Billed per OCPU per hour, or per ECPU per hour on the newer metric. This is the elastic line.
• Storage servers and expansion. Separate term based line items, standard or Extreme Flash, tied to the primary rack's end date.
• License choice. License included and bring your own license are separate products at separate rates, so the choice shows on the invoice.

There is a floor inside the elastic line. Oracle's pricing page sets a minimum of eight ECPU per database node, so compute never falls to zero while a node is running.

The single commitment on a Dedicated Region

A Dedicated Region shows no separate hardware line. You commit to consumption over five years, Oracle sizes the footprint against your forecast, and every service you run draws down the commitment. Oracle's FAQ says the starting footprint is based on your forecast for the first year.

The consequence is that there is nothing to scale down. Idle compute on Exadata Cloud at Customer can be switched off, and it stops billing. Idle capacity in a region has already been paid for by the commitment.

Worked example: what scaling down is worth

Say you run a two node VM cluster on Exadata Cloud at Customer. Quarter end and year end processing need 160 ECPU for three months of the year, and 64 ECPU covers the other nine. A year has 8,760 hours, so three months is 2,190 hours.

Scaling down after each peak cuts ECPU hours by 45 percent, and the compute charge falls in proportion at whatever rate you negotiate. The same demand pattern in a Dedicated Region saves nothing unless another workload uses the capacity you have already committed to.

The rack term factor, and why late expansion costs more

Few buyers read this clause. Oracle's Exadata Cloud at Customer price list applies a rack term factor to expansion racks and servers, which must finish when the primary rack term does. The factor is 48 divided by the smaller of the remaining rack term in months or 48.

1. Add an expansion rack at the start of a four year term and the divisor is 48, so the factor is 1.
2. Add the same rack with 12 months remaining and the divisor is 12, so the monthly rate is multiplied by four.
3. Oracle's intent is to amortize the item over the remaining term. In practice, growth late in the term is expensive growth.
4. The fix is to time expansion with a term reset, or to negotiate an extension of the primary rack term in the same order as the expansion.

Multiply the factor by the months remaining and the answer is always 48. An expansion item therefore costs 48 months of its base rate, however little of the term is left to use it. The table uses a round $10,000 monthly base rate for illustration, not an Oracle price.

We have seen this discovered in year three, after the capacity plan had already been approved. Oracle publishes the formula on its price list, so there is no dispute to be had later. Model it while the capacity plan is still a draft.

What does it take to leave each platform?

Leaving Exadata Cloud at Customer means moving databases, a project most DBA teams have run before. Leaving a Dedicated Region means moving every workload and a control plane, which few organizations have ever rehearsed.

• Data gravity. A database platform holds databases. A region holds object storage, images, identity configuration, network topology and the automation that assumes all of it.
• Skills gravity. Teams build tooling against the local region console, and that tooling does not transfer cleanly to a commercial region tenancy.
• Physical gravity. Both platforms leave Oracle owned racks in your building at the end. Agree decommissioning, removal and media handling in writing at signature, well before termination.

Price the exit before you sign either contract. If your team cannot describe how it would leave within 12 months, Oracle will hold most of the negotiating power at renewal.

How does Oracle licensing compare on the two platforms?

The licensing rules are the same on both; the cost control they give you differs. Both platforms support bring your own license and license included, under the same Oracle cloud licensing terms.

BYOL and license included

Conversion rules for owned licenses sit in Oracle's cloud licensing policy. Treat it as a policy document that Oracle can revise, and keep a dated copy of the version you relied on when you signed. Our review of the 2026 cloud licensing policy tracks what has changed.

• Same eligibility. The programs that qualify for BYOL are the same on both platforms.
• Same double counting rule. A license applied to either platform cannot at the same time cover a server on your own floor.
• Same support obligation. BYOL lowers the cloud rate and leaves the support bill on the underlying licenses untouched.

The BYOL against license included cost comparison works through the break even. Our Cloud at Customer deployment strategy guide sets out how to sequence the family for 2026 and beyond.

Does the partitioning policy apply to either platform?

No. The on premises partitioning policy governs how you count processors on hardware you own. Neither platform meters that way, because Oracle owns the hardware and bills a cloud metric.

The boundary still matters. If the same licenses also cover servers you own, keep an allocation record that shows which entitlement is deployed where at any point in time.

The cost control that exists on only one platform

On Exadata Cloud at Customer, database compute is elastic and the licensing requirement follows it. Scale OCPUs or ECPUs down and both the cloud charge and the BYOL requirement fall. Scale up for quarter end and you pay for those hours only.

A Dedicated Region has no equivalent. The commitment is set for the term, so the only way to lower the effective unit cost is to consume more of what you already bought. That puts more of the commitment to work, and the invoice stays the same.

How to check whether elasticity pays for you

Measure how uneven your database demand is before you put a value on the elastic line. Most of the evidence already sits in your own systems.

• AWR history. DBA_HIST_OSSTAT records host BUSY_TIME and IDLE_TIME at every snapshot, which gives you a CPU demand curve per database server. Default AWR retention is eight days, so extend it now if you want a year of history by the time you negotiate.
• Close calendars. Month end, quarter end and year end schedules show when peaks are planned, which is more reliable than guessing from averages.
• OCI cost and usage reports. After go live, these reports in your tenancy show ECPU hours by resource, so you can confirm the scale down schedule actually runs.

What have we seen in recent Cloud at Customer and Dedicated Region selections?

We supported roughly 12 to 18 platform selections between these products in 2024 and 2025. In most of them, the shape of the commitment settled the decision, and the technology came second. Three patterns kept coming up.

• A region pitched for a database need. Buyers who needed a database platform were shown a region, because a region is a larger deal and the same account team sells both.
• The elastic line run as a fixed cost. No one built the process to scale compute down after quarter end, so a saving that was available every quarter was never taken.
• BYOL debated at length. Eligibility was identical on both platforms in every case we modeled. It never broke the tie, yet it filled most of the evaluation meetings.

The cost of a poor fit was large. In the worst case we measured, the wrong platform meant paying about 60 percent more than the right one would have cost for the same workloads.

Why we do not accept the future proofing case for a region

The common advice is that a Dedicated Region is the strategic choice because it puts the full OCI catalog on site and future proofs the environment. We disagree. In the selections we advised, buyers who chose a region for a narrow set of workloads paid a full region commitment to run what one database platform would have carried.

No unit rate benefit came close to closing that gap. Oracle can add racks in weeks, and it advertises growth past 450 racks, so starting smaller does not close off the region later. Buy the platform that matches the workloads you have funded, and let real adoption earn the larger commitment.

Do not buy a region to run a database.

How should you choose between them?

Answer five questions in order and the platform usually picks itself. Answer them out of order and the largest deal on the table tends to win by default.

The five questions that settle it

1. What does the rule actually name? If it names the data, a database platform can satisfy it. If it names the control plane, the operator or the jurisdiction, you need a region.
2. What is not an Oracle Database? List the workloads that must stay local and are not databases. If that list is short, a region is expensive scaffolding.
3. How uneven is demand? If load is seasonal or project driven, the elastic compute line on Exadata Cloud at Customer is worth real money. If it is flat, that advantage disappears.
4. When does capacity need to grow? Run the rack term factor against your plan. Growth in the back half of a term costs materially more than growth at the start.
5. Who will run the room for the whole term? Both options put Oracle hardware on your floor. Only one puts a whole region there.

What neither platform fixes

• A licensing baseline problem. If your on premises position is unclear, moving it onto Oracle owned hardware does not clean it up. It relocates the problem.
• Support cost on owned licenses. BYOL keeps the support line alive on every entitlement you bring.
• Price. Both are decisions about control with a price attached. Benchmark each against the same workloads in a commercial OCI region.

A timeline for the decision

For a Dedicated Region, start earlier than this. The data center work has to finish before Oracle can install, and the commitment is harder to reshape once the site is built.

What will Oracle's account team say, and how should you respond?

Expect the same few lines in most evaluations. Each has a reasonable answer that keeps the discussion on your workloads and your contract.

• "A Dedicated Region gives you the full OCI catalog on site, so you are covered for the future." Ask which of those services are funded in the next two years, and size the commitment to that list only.
• "Region pricing matches the public cloud, so the unit rates are no worse." Agree on the unit rates, then ask for the total commitment and what happens if consumption falls short in any year. The floor is what you are buying.
• "BYOL works on both, so licensing is not a factor." Accept it, take BYOL off the agenda, and spend the meeting time on term, ramp, expansion pricing and exit.
• "You can add expansion racks at any time." Ask for the rack term factor to be shown on the quote for expansion in years two, three and four, and for a priced option to extend the primary rack term.
• "We will size the region to your forecast." Ask to see the forecast Oracle used, and correct it before it becomes your first year commitment.

Which contract terms should you ask for?

Ask for seven terms: a compute price hold, priced term extension, a ramp, shortfall carry forward, a benchmark right, refresh rules and exit terms. Settle them before signature on whichever platform wins, because Oracle has little reason to revisit them afterwards.

• A price hold on compute rates. Fixed OCPU or ECPU rates for the whole rack term keep the elastic line predictable.
• A priced term extension with expansion. A right to extend the primary rack term when you add capacity resets the rack term factor instead of multiplying the rate.
• A ramped region commitment. Early years in a region are spent migrating workloads onto it, so the yearly commitment should rise in step with a realistic migration plan.
• Shortfall treatment. Set out in writing what happens to unused region commitment at the end of each year, and ask for it to carry forward.
• A benchmark right. Oracle says region pricing is intended to match its public regions, so ask for the right to compare unit rates against a commercial region in the contract.
• Refresh. Agree how and when hardware is refreshed during the term, and that a refresh does not restart the term.
• Exit and decommissioning. Removal of racks, handling of storage media, return of data and the timeline for each.

Our Oracle cloud negotiations guide covers ramp, benchmark and exit terms in more depth, and DRCC pricing and licensing explains the commitment mechanics on the region side.

What to do next

1. Write the requirement. Put it in one sentence and underline what it names: the data, the control plane or the operator.
2. List the local workloads. Mark every workload that must run locally and flag the ones that are not an Oracle Database. If that list is short, price Compute Cloud at Customer alongside the two headline options.
3. Model both bills separately. Fixed infrastructure plus elastic compute on one side, a single consumption commitment on the other, using your own AWR demand curve.
4. Run the rack term factor. Test it against your capacity plan and bring growth forward if the numbers call for it.
5. Confirm BYOL eligibility on both. It will probably be identical and will not break the tie, so settle it quickly.
6. Compare total contract value. Use the full term, not the annual figure, against the same workloads in a commercial region.
7. Negotiate the terms above. Ramp, benchmark, refresh and exit, before signature on whichever platform wins.
8. Get an independent view. Talk to our independent Oracle advisory team before you commit to either term.

Frequently asked questions