Oracle Database@Azure Licensing: The Multicloud Path

What Database@Azure is

Oracle Database@Azure places genuine Oracle Cloud Infrastructure database hardware, including Exadata, physically inside Microsoft Azure data centres, connected to the Azure fabric so that the database sits next to your Azure applications with no cross cloud latency. The critical point for licensing is that the database service is OCI, not Azure: Oracle owns and operates the database estate, Azure provides the surrounding region and the network adjacency. That ownership is what determines the licensing model, and it places Database@Azure firmly inside the Oracle OCI licensing regime rather than the hyperscaler policy regime.

This distinction is the entire article in miniature. Buyers see the word Azure and assume the third party cloud vCPU policy applies. It does not. Because the database runs on real OCI infrastructure, the OCI rule governs, and that rule is both stricter per core and contractually firmer than the policy. Confusing Database@Azure with running Oracle on an Azure virtual machine, which is covered separately under Oracle on Azure, leads to mispriced business cases in both directions.

How Database@Azure is metered

Metering follows the OCI rule exactly. Each OCPU of the Oracle Database service requires one Enterprise Edition processor licence under BYOL, or is bundled into the per OCPU rate under License Included, with no core factor and no hyperscaler vCPU discount. Because the underlying hardware is Exadata, the Exadata service tiers and their bundled options apply just as they do in a native OCI region, a model detailed under Exadata Cloud Service.

The table makes the counterintuitive result plain: per core, Database@Azure is counted on the OCI basis, which is less generous than the Azure VM vCPU policy but is delivered as a fully managed Exadata service with bundled options. You are not buying cheaper counting; you are buying a managed engineered system adjacent to Azure. The licence cost should be weighed against the operational value, not against the raw vCPU policy that applies to a self managed VM.

Database@Azure versus Oracle on Azure

The two paths sound alike and license entirely differently. Oracle Database@Azure is OCI hardware in an Azure building, metered per OCPU on the OCI rule, fully managed by Oracle. Oracle on an Azure virtual machine is software you install on Azure compute, metered under the third party cloud licensing policy using the two vCPU per licence rule, and managed entirely by you. The first is a service; the second is self deployment on infrastructure.

Choosing between them is a trade of counting efficiency against management burden and adjacency. The Azure VM path can count more cheaply per core under the policy, but you carry the patching, high availability, and audit exposure of a self managed Oracle estate, and you depend on a policy Oracle can revise. Database@Azure costs OCI counting but removes the management burden and gives true low latency adjacency to Azure applications. The right answer depends on workload criticality and the value of adjacency, a judgement the cloud and OCI licensing practice helps frame.

BYOL or License Included

As with any OCI service, you may bring owned licences under BYOL and pay a reduced infrastructure rate, or take License Included and let Oracle bundle the licence into the per OCPU rate. For estates migrating an existing Oracle Database footprint into Azure adjacency, owned licences are usually available, which tilts the economics toward BYOL when those licences are supported and genuinely free for redeployment.

Where the deployment is net new and no spare entitlement exists, License Included avoids a perpetual purchase and is frequently cheaper across a three year horizon. The election is per workload and independent of the platform choice, so size the OCPUs first, then price both models against that size, then elect. The break even logic is the same one set out for native OCI under License Included.

Universal Credits and billing

Database@Azure consumption draws against an Oracle Universal Credits commitment in the same way as native OCI, even though the invoice can be arranged through the Azure marketplace. That dual billing path is a convenience, not a change to the licensing model: the credits fund OCI consumption, and the OCPU rule sets how many credits each database draws. Sizing the credit commitment to the realistic activated OCPU plan, not to a peak ceiling, is the same discipline that governs any OCI commit.

The marketplace billing does have one practical benefit: Database@Azure spend can often count toward an Azure commitment, which is valuable for buyers with a large Microsoft commitment to retire. That is a procurement optimisation rather than a licensing one, but it can materially change the effective cost, so it belongs in the business case alongside the OCPU and model decisions.

When Database@Azure makes sense

Database@Azure earns its keep when the application tier lives in Azure and the database needs genuine low latency adjacency, when you want a fully managed Exadata service rather than a self managed VM, and when counting on the OCI rule is acceptable because the operational value justifies it. It is the natural path for an organisation standardised on Azure for applications that nonetheless wants Oracle's managed database with no cross cloud network penalty.

It makes less sense when the workload is small, latency insensitive, or where the cheaper vCPU counting of a self managed Azure VM outweighs the management burden. For those cases the Oracle on Azure path or a native OCI region may be the better economic answer. The decision is a genuine multicloud architecture choice, not a default.

How to govern it

Governance mirrors native OCI with one addition for the billing path. Size the credit commitment to the activated OCPU plan. Elect BYOL or License Included per workload after pricing both. Confirm the Exadata service tier and its bundled options, and block out of tier options without entitlement. Treat every OCPU scale up as a licence event checked against held entitlement under BYOL. Reconcile activated OCPUs and options against entitlement on a dated schedule. And track whether the marketplace billing is retiring an Azure commitment as intended.

Because the service is Oracle managed, the day to day administrative drift risk is lower than on a self managed VM, but the model election and credit sizing decisions carry the cost, so the reconciliation focuses there. Maintaining that dated record is the practical work the database licensing practice performs across any multicloud estate.

The buyer side view

Database@Azure is OCI infrastructure in Azure data centres, so it is licensed on the OCI rule, one OCPU to one Enterprise Edition processor licence, not on the cheaper Azure VM vCPU policy. You buy managed Exadata and true Azure adjacency, and you pay OCI counting for it. Size OCPUs first, elect BYOL or License Included after pricing both, fund it through Universal Credits, and exploit the marketplace path to retire an Azure commitment where you have one. Do not confuse it with self deploying Oracle on an Azure VM. To model a Database@Azure business case against the alternatives, request a consultation.