Oracle Dedicated Region in 2026: the commitment you sign and the room you supply.

An Oracle Dedicated Region is two commitments in one contract: years of OCI consumption, and a room built to Oracle's specification. Most buyers negotiate the first and discover the second in the site survey, which is the wrong order.

What does Oracle install when you buy a Dedicated Region?

Oracle installs a complete, self contained OCI region inside your facility and runs it as a managed service. You never own the hardware. Oracle ships it, racks it, patches it and refreshes it. You sign a multi year consumption commitment and agree to host the racks in a room that meets Oracle's environmental specification.

On its Dedicated Region page, Oracle describes an expandable footprint that starts as small as three racks and scales to more than 450, with over 200 OCI services running behind your perimeter.

How small is the smallest Dedicated Region now?

Smaller than most buyers assume. Oracle has cut the entry configuration twice since launch, which widens the group of companies that can credibly consider one.

• June 2022. Oracle announced a redesigned OCI Dedicated Region that needed 60 to 75 percent less data center space and power on average, and lowered the published price point with it.
• September 2024. At Oracle CloudWorld, Oracle announced Dedicated Region25, starting at only three racks with a 75 percent smaller launch footprint and deployment measured in weeks. The release promised availability in the following calendar year and support for more than 150 AI and cloud services.
• Today. The footprint range sits on Oracle's public product page. Your price does not, so every offer has to be tested on its own terms.

The practical effect is that the room requirement is now within reach of a mid sized enterprise data hall. The commitment changed much less than the hardware did, which is why most of this page is about the contract.

What is missing from your region on day one?

Full parity with public OCI does not arrive on day one, and the region is isolated by design. Oracle's Dedicated Region FAQ keeps it separate from Oracle's commercial public cloud regions. The two are not connected, and today they cannot be managed from a single console.

• Service catalog lag. New OCI services launch in commercial regions first. Ask for the current Dedicated Region service list in writing, with dates for anything you depend on, and set the headline service count aside.
• Separate control plane. Identity, tenancy and billing are managed separately. Features that assume a connection to a public region may simply not apply.
• Connectivity. Oracle points to FastConnect for dedicated private connections. That means circuits, carriers and lead times you procure and pay for yourself.
• Availability target. The FAQ cites a compute availability objective of 99.95 percent across fault domains. It is a service target for Oracle's infrastructure and makes no promise about your building's power or cooling.

What must your data center provide before Oracle will build it?

You provide the room, the power, the cooling, the network drops and the people. Oracle provides and operates everything inside the racks. Oracle's product page lists floor space, racks, data center power and cooling, and data center personnel as the customer's share, and none of it is open to negotiation.

The environmental numbers your facilities lead signs up to

Oracle publishes the engineering specification for the rack families used in these deployments. The figures below come from Oracle's site requirements documentation and its site checklists.

• Rack envelope. Roughly 2000 mm high, 601 mm wide and 1237 mm deep, with populated racks weighing in the region of 470 to 900 kg.
• Clearance. 1219 mm at the front for cold air intake and 914 mm at the rear for exhaust. These are clearances measured from the rack face, which is a stricter test than aisle width.
• Raised floor. A minimum depth of 46 cm, floor to ceiling height of at least 3.2 m, and permission to lift tiles for cabling and service.
• Cooling. Perforated tiles rated 400 CFM or greater, with a full rack typically needing four of them. Airflow runs front to back, and no rack may exhaust into another rack's intake.
• Temperature and humidity. An operating range of 5 to 32 degrees Celsius with an optimal band of 21 to 23 degrees, and relative humidity optimally 45 to 50 percent, non condensing.
• Power. Two PDUs per rack, with options in the 15, 22 and 24 kVA range depending on region and phase. Oracle asks for one dedicated breaker per power cord, receptacles within 2 m of the rack, feeds from two separate grids, and a UPS.

None of that is unusual for a purpose built data hall. All of it is a problem in a converted server room, in a leased suite where you do not control the tiles, or in a facility already running close to its cooling limit.

Why the access route is where projects slip

Each rack has to travel from the loading dock to its tile without damage. Oracle's documentation specifies that route in detail, and your building either meets it or needs work.

• Doorways. Minimum 2184 mm height and 1270 mm width with the shipping pallet, or 2040 mm by 640 mm once unpacked.
• Elevators. Minimum internal depth of 1625 mm with the pallet and 1240 mm without, plus a rated dynamic load for the rack in transit.
• Ramps and floors. A maximum incline of 6 degrees, and a route free of raised pattern flooring that would catch castors.
• Delivery. A tail lift or side lift on the carrier, plus dollies, pallet jacks, steel plates or floor covers as the route demands. The checklist also asks about truck size limits and time windows at your dock.
• Staging. An air conditioned, protected unpacking area, which prevents thermal shock and particle contamination before the rack reaches the floor.
• Facility basics. Emergency power shutoff, a fire protection system, antistatic flooring, and space to keep spare parts.

Badges, background checks and the camera question

Oracle field engineers need to get into your data hall, sometimes at short notice, for the full term. The logistics checklist asks you to declare your access rules up front, and those rules then limit how fast Oracle can fix anything.

• Clearances. You state which background checks or security clearances Oracle personnel need, the process Oracle must follow, and how many days of notice you require.
• Devices. You state whether laptops, phones and cameras are allowed on the floor. In defense and government sites the answer is routinely no, which changes how remote hands work.
• Escorts. If every visit needs an escort, your own staffing model becomes part of Oracle's maintenance service level.
• Labor rules. You declare whether union labor is required for delivery or installation, which affects both cost and scheduling.

Write these constraints into the contract as customer obligations with agreed notice periods. Otherwise a delayed repair caused by your own badge process turns into an argument about Oracle's service credits.

How do you check whether your room qualifies before Oracle's site survey?

Run your own survey against Oracle's published checklists before Oracle's engineers arrive. A facilities engineer can do it in a few days, and the result tells you whether you are ready to negotiate at all.

1. Walk the route with a tape measure. Measure every door, corridor, elevator car and turn from the dock to the target tiles, and compare each against the packed and unpacked dimensions above. Photograph thresholds and ramps.
2. Pull the floor loading rating. Get the rated load for the raised floor and the slab from the building drawings or the landlord. A populated rack of up to 900 kg rolling on castors creates point loads that older raised floors were never rated for.
3. Read the cooling trend. Ask for 12 months of CRAC load and cold aisle temperatures from your building management system, because the nameplate capacity says little. Headroom on paper can disappear in the hottest weeks of summer.
4. Trace the power path. Confirm two feeds from separate grids to the target row, spare breaker positions for one breaker per cord, UPS capacity for the added load, and receptacles that match the PDUs Oracle will specify.
5. Check your rights in the building. In a leased or colocation suite, confirm that the lease allows you to lift tiles, add circuits and keep the space for the full five years plus any renewal.
6. Start the network worksheet early. Oracle's final preinstallation checklist asks for IP address availability, DNS registration and labeled cabling from your network equipment. Your network team's change calendar often sets the real go live date.

If any item fails, you have a facilities project to scope and price before you have a cloud contract to sign. Put that cost in the business case next to the Oracle commitment, because it will otherwise land on a different budget line.

What are you committing to, and for how long?

You commit to five years of consumption, and the initial hardware footprint is sized on what you forecast for year one. Oracle's FAQ states both points: the order is a consumption based commitment over a period of five years, and the starting footprint follows the customer's forecasted first year consumption.

Oracle also says the pricing is intended to match its commercial public cloud regions. The unit rates will look familiar. The commitment shape around them will not.

What Oracle has published about the commitment, and when

The public numbers have changed twice, and that history is useful at the table. Oracle has restated the entry point each time it wanted a wider market, so treat the current minimum as a commercial position open to discussion.

• 8 July 2020. Oracle's launch blog for Dedicated Region Cloud at Customer stated a 500,000 dollar per month commitment over three years, sold purely on consumption.
• 21 June 2022. The press release for the redesigned region put the price at around 1 million dollars a year for a typical customer.
• Current terms. The FAQ now describes the five year term. The term got longer while the published annual number got smaller, which makes it a different deal, and not necessarily a cheaper one.

Compare total contract value across the whole term rather than the annual figure. A smaller annual minimum over a longer term can commit you to more money than a larger one over a shorter term, and it keeps you committed through two extra budget cycles.

A worked example: flat minimum against a ramped minimum

Say your business case forecasts $2.7 million of OCI consumption in year one, rising to $3.5 million by year five. Real year one consumption comes in at $2.0 million because the second migration wave slips by two quarters. Assume the contract sets an annual minimum and unused commitment does not carry forward.

The flat minimum costs $1.0 million for capacity you never used, all of it in the first two years, when the project is most exposed. The ramped version commits $12.5 million, against $13.5 million for five flat years at $2.7 million, and pays for nothing idle.

Oracle will want each ramp step tied to something real, which is a fair request and a useful discipline for your own program office.

Why the year one forecast decides the negotiation

The forecast is used twice, and usually only one use gets discussed. It sizes the equipment Oracle ships, and it sets the minimum you are asked to sign.

1. Your architects produce a forecast to justify the business case, so it is optimistic by construction.
2. Oracle sizes the initial footprint from that forecast, because it has to order hardware against something.
3. The minimum is then set at a level that makes the footprint economic for Oracle.
4. The migration slips, as migrations do, and you pay the minimum anyway for the remaining years.

Build a second, deliberately conservative year one forecast, kept separate from the business case version, and let that one drive the ramp. It will look less impressive in the steering committee, and it will cost less in year two.

The consumption forecast you write to get the project approved is the same document Oracle uses to size your floor. Write it as if you will be held to it, because you will be.

Which contract terms should you ask for before you sign?

Ask for terms that match the commitment to the migration you can deliver, and that spell out the facility split. Oracle's published material describes the service in detail and says little about what happens when your project or your building runs late, so those terms have to come from you.

• Ramped minimum tied to workloads. Each step up names a workload and a target date, so a slipped migration shifts the step instead of producing idle spend.
• Carry forward of unused commitment. Unused amounts in the early years roll into later years instead of expiring. It is the cheapest protection against a late migration.
• Commitment start at acceptance. The first year starts when the region passes acceptance, and a failed or delayed site survey pushes the start date back.
• Rate parity in writing. Put Oracle's public statement on price parity into the contract, including later list price reductions and any discount you hold on public OCI.
• Service catalog exhibit. Attach the list of services available at go live, with committed dates for any service your workloads need later.
• Expansion pricing. Fix the rates and lead times for adding racks, so the case for oversizing at signature loses its force.
• Facility event definitions. Define what counts as a customer facility event and how it enters the availability calculation, before the first cooling incident forces the question.
• Exit and media handling. Set out data return, the decommissioning timeline and media destruction certificates for term end and early exit alike.

For the wider commercial side, including benchmarks and exit rights on OCI deals generally, see our guide to Oracle cloud negotiations.

Should you bring your own licenses or pay license included rates?

You get the same two options as on public OCI: license included rates, or bring your own license (BYOL) for programs you already own with active support. Putting the region in your building does not change that choice.

It does change the timing. The decision has to be settled before the footprint is sized, because BYOL and license included deployments consume credits at very different rates for the same workload.

Settle BYOL before the site survey

If you plan to bring owned Database licenses, count them before the forecast is written. A large owned base lowers your credit burn, which lowers a reasonable minimum, which in turn lowers the footprint Oracle needs to ship.

• Count what you own. List Processor and Named User Plus entitlements with current support, verified against your ordering documents rather than a support renewal quote.
• Check the conversion rules. Oracle's cloud licensing terms sit in a policy document that Oracle can revise. Save a dated copy of the version you relied on; our note on the current Oracle cloud licensing policy tracks the changes.
• Avoid double counting. A license applied to the region cannot also cover a server elsewhere on your floor.
• Keep the support line visible. BYOL lowers the cloud rate, but you still pay support on the underlying licenses, so the saving is smaller than the rate card implies.

The money mechanics, including what the fee covers and what is billed separately, are on our DRCC pricing and licensing page. If you are still choosing between a full region and a database platform, start with the Cloud at Customer comparison.

What have we seen in recent Dedicated Region negotiations?

Across roughly 10 to 15 Oracle Dedicated Region and Cloud at Customer engagements we supported in 2024 and 2025, the signed commitment ran a median 35 percent ahead of real year one consumption. The same three patterns came up again and again.

• The forecast became the contract. The consumption forecast used to size the footprint was written by the team that wanted the project approved, then reused word for word as the contractual minimum.
• Facilities arrived late. Facilities were consulted after heads of terms. In several cases the chosen room failed on floor loading or raised floor depth, while power turned out to be fine.
• Hosting costs had no owner. The power draw, the cooling load, the badge process and the spare parts space all landed on a different budget line from the Oracle deal, and no one had priced them.

A five year committed term was the typical starting point we negotiated against in that period. We spend most of the effort on the shape of the commitment inside that term, because that is where the money is.

When does a Dedicated Region fit, and when does it not pay?

It fits when a rule, rather than a preference, stops the data from leaving your control, and when you would consume the minimum anyway. Everything else belongs in a public region conversation.

The three reasons that survive scrutiny

Only three reasons hold up under a hard read. Cost is not one of them, since Oracle prices the region to match its public cloud and you add the hosting on top.

• Sovereignty. A law, a license condition or a supervisory expectation requires the data and the control plane to stay in a jurisdiction, or under your physical control, and no commercial region satisfies it.
• Latency. A production process, a trading system or an industrial control loop needs single digit millisecond access to cloud services, and the nearest commercial region cannot deliver it.
• Regulation of the operator. Your regulator restricts who may physically access the media, or requires exit and audit rights that a shared region cannot give you.

Test each one against a written source. A supervisory expectation you can cite is a reason. A risk committee's discomfort is a preference dressed up as one.

Six situations where a Dedicated Region does not pay

These are the cases where we have advised buyers to walk away, or to buy something smaller such as Exadata Cloud@Customer or Compute Cloud@Customer. Our Cloud at Customer guide covers those options.

• The workload is one database platform. You would be buying a full cloud region to run one service. A database platform is the cheaper answer.
• A commercial region already satisfies the residency rule. If Oracle operates a region in country and your rule says in country, the case falls away.
• Your migration is unfunded past year one. A minimum that outruns a stalled migration is the most common way this deal goes wrong.
• You do not control the facility. In a leased suite you may not be able to guarantee tile depth, floor loading or a second power feed for five years.
• Your Oracle footprint is shrinking. If you are consolidating or divesting, a five year minimum is the wrong shape for falling demand.
• No team owns day two. If no named team has capacity for escorted access, capacity planning and power reporting, the region will be left without an operational owner.

How the decision changes with scale

• A 3 to 10 rack region. The room is usually achievable in an existing enterprise data hall. The larger risks are the commitment relative to your total Oracle cloud spend and the internal hosting cost, which is a bigger share of the total at this size.
• A region of dozens of racks. The buyer usually runs a purpose built facility, so the site is less often the problem. The questions move to service catalog parity, operator access, expansion pricing and what exit looks like after five years.

Why we advise against sizing for your three year target state

The usual advice is to size a Dedicated Region for your three year target state, so you have room to grow into it. We disagree. In the engagements we supported, that approach meant paying a large annual minimum for capacity the migration had not yet filled, with commitments a median 35 percent ahead of real consumption early on.

Oracle can add racks later, and its own product material presents expansion as the normal path. Buy for the workloads you have funded and dated, and put expansion pricing in the contract. Growing into a region is a project you can manage, while paying for capacity you have not filled is money you do not get back.

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

Expect a familiar set of arguments in a Dedicated Region sales cycle. Most of the replies rest on Oracle's own published material, which the account team cannot easily dispute.

• "Size for where you will be in three years, because adding racks later costs more." Ask for expansion rates and lead times in the contract. If Oracle will not hold them, that tells you how firm the claim is.
• "Pricing is the same as public OCI, so there is no premium." Rate parity still leaves you carrying a five year minimum plus the cost of power, cooling, space and staff. Compare total cost against a commercial region with those lines included.
• "The commitment level is standard." Oracle has published three different commitment shapes since 2020. Ask what makes the current one fixed when the previous two were not.
• "We can deploy in weeks." Oracle's clock starts when your room, circuits and access approvals are ready, and its own FAQ talks about months. Plan against your facility timeline.
• "Facilities can finish the site survey after signature." Decline, and make a passed site survey a condition of the commitment start date. A room that fails after signature leaves you paying for a region you cannot host.

Who runs it after go live, and who gets the call at 3am?

Oracle runs everything inside the racks, and you run the room, which means the room's uptime is yours. Oracle's FAQ makes the customer responsible for data center uptime, physical compliance of the facility, keeping temperature and humidity within agreed levels, and ensuring power and cooling.

That is a reasonable split with a sharp edge. If your chiller fails, the region degrades, and the availability objective was never a promise about your plant.

The responsibility split that surprises people

Three obligations move to you that would sit with Oracle in a commercial region.

• Facility availability. Power and cooling continuity for the Oracle racks is your obligation for the length of the term.
• Environmental compliance. You have to keep the hall inside the agreed envelope continuously, and an average over the month does not count.
• Access provisioning. Oracle needs timely physical access for maintenance, and your process governs how fast that happens.

Oracle keeps hardware maintenance, troubleshooting, patching, feature rollout, planned operational audits, and secure media handling and destruction in its own controlled area. Ask to see the media process documented before you sign, particularly if your regulator will want it.

What an outage looks like when the region is in your building

It differs from a public region outage in one important way: you are now a participant in the incident as well as a customer of it.

1. Detection is joint. Your building management system may see the cause before Oracle's telemetry sees the symptom.
2. Escalation crosses two organizations, and the boundary between them is physical rather than logical.
3. Remediation may require a person on your floor, at your notice period, through your badge process.
4. Root cause is often about the room, and the room is your evidence to produce.

Run a tabletop exercise with facilities, the Oracle account team and your incident commander before the region carries production, and write the notice periods you commit to into the agreement.

How long does it take to go from decision to production?

Our planning assumption is about 12 months from the first serious conversation to production for a room that needs modest work. Oracle quotes weeks to months once the room is ready, so the schedule is set by your facility, your network and your security approvals.

For how a Dedicated Region fits into the rest of your Oracle spending over the same five years, our Oracle CIO Complete Playbook sets out the longer plan, and the Oracle practice page explains how we support these negotiations without reselling anything.

What to do next

1. Name the rule. Write down the residency, latency or regulatory rule in one sentence, with the source you would show a regulator. If you cannot, stop here.
2. Test the public option. Check whether a commercial OCI region in the same jurisdiction already satisfies the rule, and record the answer.
3. Bring facilities in before heads of terms. Test the candidate room against clearance, raised floor depth, floor loading, tile CFM and dual power feeds.
4. Settle licensing first. Count your owned Oracle licenses and decide the BYOL position before the footprint is sized.
5. Write a second forecast. Build a deliberately conservative year one consumption forecast, separate from the business case version.
6. Negotiate the shape. Ask for a ramped minimum with each step tied to named workloads and dates, carry forward of unused amounts, and a start date at acceptance.
7. Compare the whole term. Set total contract value, plus hosting costs, against the same workloads in a commercial region, and get exit, hardware refresh, service catalog parity and access notice periods into the contract before signature.
8. Rehearse an outage. Run a joint incident exercise with facilities and Oracle before production lands.

Frequently asked questions