Oracle Database on Google Cloud: Licensing on GCP

Two paths on GCP

There are two distinct ways to run Oracle Database on Google Cloud, and they license differently, so the first task is to know which one you are deploying. The first is self deployment: you install Oracle Database on a Google Compute Engine virtual machine and run it yourself. The second is Oracle Database@Google Cloud, where Oracle places genuine OCI database hardware inside Google data centres as a managed service. The licensing model turns entirely on this distinction, just as it does for the equivalent Azure paths, and getting it wrong misprices the deployment from the start. Both sit within the broader Oracle OCI licensing picture.

The short version: the self deployed VM path uses the third party authorized cloud vCPU policy, while the managed Database@Google Cloud path uses the OCI per OCPU rule. The first counts more cheaply per core but puts management and audit burden on you; the second counts on the stricter OCI basis but is fully managed and contractually firmer. Everything below unpacks that trade.

Self deployed on a Compute Engine VM

When you install Oracle Database on a Google Compute Engine VM, Google Cloud Platform is a recognised authorized cloud, so Oracle's cloud licensing policy applies. Under that policy, with hyperthreading enabled the convention is two vCPUs per Enterprise Edition processor licence; Standard Edition is counted on socket equivalents within vCPU bands. There is no core factor on GCP, just as there is none on AWS or Azure, because the policy substitutes the vCPU rule for the core factor table.

This path gives you full control of the database and the cheaper per core counting, but it also gives you the full operational and compliance load: patching, high availability, backup, and, critically, the audit exposure of a self managed Oracle estate on infrastructure Oracle does not control. The counting rules and the authorized cloud list that make this path viable are detailed under authorized cloud environments.

Oracle Database@Google Cloud

Oracle Database@Google Cloud is the managed alternative: real OCI Exadata and database hardware sited inside Google data centres, adjacent to your Google Cloud applications with low latency. Because the database runs on Oracle owned OCI infrastructure, it is licensed on the OCI rule of one OCPU to one Enterprise Edition processor licence, with no vCPU discount, exactly as the equivalent service on Azure behaves. You are buying a managed OCI service that happens to live in a Google building.

The trade is identical to the Azure case: OCI counting and a managed engineered system against vCPU counting and self management. Database@Google Cloud removes the patching and audit burden and gives genuine adjacency to GCP services, at the cost of the stricter OCI counting. It is the right path when the application tier is on Google Cloud and the workload justifies a managed database with no cross cloud latency.

How GCP counts

The vCPU to licence mechanics, including the hyperthreading distinction that produces the two vCPU rule, are the same across all authorized clouds and are worked through in OCPU versus vCPU. The single most important number on a GCP VM is therefore whether hyperthreading is on, because it doubles or halves the licence count for a given vCPU allocation.

BYOL on Google Cloud

On the self deployed VM path, you supply your own Oracle licences; there is no License Included option, because Google is not selling you Oracle as a service. Your owned Enterprise Edition or Standard Edition entitlements must cover the vCPU based requirement, and they must be on active support. This is BYOL in its purest form, with the licence count set by the policy and the entitlement coming entirely from you.

On the Database@Google Cloud path, the standard OCI choice returns: BYOL with owned licences at a reduced rate, or License Included with the licence bundled into the per OCPU rate. As elsewhere, migrations of an existing estate usually favour BYOL when licences are free and supported, while net new capacity often favours License Included. Price both against the activated OCPU plan before electing.

The GCP audit risks

The self deployed VM path carries the higher audit risk, because Oracle has no visibility into your Google VMs and will rely on a script based review to count vCPUs, confirm hyperthreading state, and check options enabled. The common findings are the same as on any hyperscaler: hyperthreading assumptions that do not match the running configuration, options enabled and forgotten, and non production instances that were never counted. Defending a self managed GCP estate is squarely cloud and OCI licensing work.

Database@Google Cloud lowers this risk because Oracle operates the service and the activation telemetry exists, but it does not remove the need for governance: the model election and OCPU activation still drive cost and still need a dated reconciliation against entitlement. Neither path is unmonitored; they simply relocate where the exposure sits.

How to choose the path

Choose the self deployed VM path when you want maximum control and the cheaper vCPU counting, you have owned licences to bring, and you can carry the management and audit burden. Choose Database@Google Cloud when your applications run on Google Cloud, the workload needs low latency adjacency and a managed database, and OCI counting is acceptable for the operational value. Size the deployment, count it under the correct model, and price both before committing.

For many estates the answer is a mix: latency insensitive or smaller databases on cheaper self managed VMs, critical adjacent workloads on the managed service. Mapping the estate to the right path per workload, rather than defaulting the whole estate to one, is the optimisation the database licensing practice performs.

The buyer side view

Oracle on Google Cloud is two products. A self deployed Compute Engine VM uses the authorized cloud vCPU policy, generally two vCPUs per Enterprise Edition licence, and puts management and audit burden on you. Oracle Database@Google Cloud is managed OCI hardware in Google data centres, counted on the stricter one OCPU to one licence rule. Confirm hyperthreading state on any VM, bring supported licences, and map each workload to the path that fits its criticality and adjacency needs. To model the two GCP paths against your estate, request a consultation.