Oracle Database@Google Cloud — Full Licensing and Architecture Guide

Oracle Database@Google Cloud was announced in September 2024 as the third major Oracle Database@Hyperscaler service, joining Oracle Database@Azure (general availability since 2023) and Oracle Database@AWS (general availability progressively through 2025 – 2026). The service deploys physical Oracle Exadata X10M infrastructure inside Google Cloud regions, operates the Oracle estate through Oracle Cloud Infrastructure staff, and exposes the Database through OCI-managed control plane to Google Cloud customer workloads. The commercial structure mirrors the established Database@Hyperscaler pattern with three procurement routes: Oracle Universal Credits, Google Cloud Marketplace, and direct Oracle invoicing.

For the enterprise customer running Oracle Database workloads alongside Google Cloud analytics, the service collapses the historical cross-region latency penalty between Oracle Database and BigQuery into a sub-millisecond intra-region private endpoint. For the customer carrying Oracle Database licence inventory from a ULA exit or post-consolidation position, the BYOL economics on Database@Google Cloud absorb that inventory on a managed Exadata footprint. For both, the audit and compliance position is novel — Oracle LMS interpretation of Database@Google Cloud deployments is being established through the first wave of engagements, and the buyer-side defence framework must be built deliberately.

This guide covers the architecture, the licensing rules, the commercial models, the buyer-side comparison against alternatives, and the audit defence framework. For the broader cloud licensing context, see the Oracle cloud licensing master guide. For the parallel AWS architecture, see Oracle Database@AWS architecture and licensing guide.

The architecture — Oracle Exadata inside Google Cloud regions

Oracle Database@Google Cloud is delivered through dedicated Oracle Exadata X10M infrastructure installed in Google Cloud data centres. The initial 2025 regional availability covers us-east4 (Ashburn), us-west1 (Oregon), europe-west2 (London), europe-west4 (Netherlands), and asia-southeast1 (Singapore), with progressive regional expansion through 2026. The infrastructure is operated and managed by Oracle Cloud Infrastructure operations under an Oracle service framework; Google Cloud provides the physical facility, power, cooling, and the high-bandwidth network connectivity to Google Cloud native services.

From the customer's perspective, the Database@Google Cloud environment appears as a standard OCI Exadata Database Service tenancy provisioned inside Google Cloud regions, accessible through the OCI Console, OCI CLI, and OCI APIs. Google Cloud workloads consume from the Oracle Database through private endpoints inside the customer's VPC, with the Google Cloud analytics stack (BigQuery, Vertex AI, Dataflow, Cloud Composer) accessing the Oracle Database tables through low-latency intra-region connections without cross-region egress charges.

The commercial models — three procurement routes

Route 1 — Oracle Universal Credits

The customer commits to a multi-year Oracle Universal Credits consumption value and draws Database@Google Cloud consumption against the commitment. The Universal Credits route delivers contractual discount on the consumption rate (typically 8 – 22% against the on-demand rate depending on commitment size and term) plus Support Rewards eligibility (25 cents per $1 of consumption applied against eligible on-premise Oracle support). This is the model most large Database@Google Cloud deployments use, because the Support Rewards capture against the customer's residual on-premise Oracle support spend materially improves the total cost position.

Route 2 — Google Cloud Marketplace

The customer procures Oracle Database@Google Cloud through Google Cloud Marketplace, billed on the Google Cloud invoice and drawing against the customer's Google Cloud Committed Use Discount. Suits customers with an existing Google Cloud CUD commitment they want to consume against; the unit pricing is comparable to the OCI direct routes but the commercial structure folds into Google Cloud-side commercial mechanics rather than Oracle-side. The model is most useful for customers whose internal procurement function prefers single-supplier consolidation onto Google Cloud.

Route 3 — Direct Oracle Invoicing

The customer procures Database@Google Cloud directly from Oracle on standard Oracle Ordering Document terms, billed on the Oracle invoice independent of any Google Cloud commitment. The route suits customers without significant Google Cloud commercial commitment and customers wanting the Oracle invoicing routed through their existing Oracle Master Agreement framework. The pricing is published in the Oracle Pricing List and is subject to standard Oracle Deal Desk discounting.

The licensing rules — what BYOL covers and what it does not

BYOL coverage on Database@Google Cloud

Covered with standard Oracle Database Enterprise Edition processor licences: Oracle Database Enterprise Edition core engine, deployed on Database@Google Cloud OCPUs at the standard Database@Hyperscaler conversion (typically two OCPUs per Processor licence on the standard Exadata configuration).

Covered with the corresponding options licences: Partitioning, Diagnostics Pack, Tuning Pack, Advanced Compression, Advanced Security, Real Application Clusters — each option must be separately licensed at the deployed OCPU footprint matching the underlying Database Enterprise Edition licence quantity. The BYOL discipline requires the same forensic right-sizing that applies to on-premise Database deployments. See the Oracle Database licensing master guide.

Embedded in the infrastructure subscription: Exadata-specific features (Smart Scan, Storage Indexes, Hybrid Columnar Compression, Smart Flash Cache) are included in the Database@Google Cloud Exadata infrastructure rate and do not require separate Oracle Exadata Database Machine licences. This is the same BYOL economic benefit available on Database@AWS and Database@Azure and is not available on self-managed Oracle on Google Compute Engine.

BYOL does NOT cover

Database@Google Cloud infrastructure components (the Exadata storage cells, the RDMA network, the platform management) are not BYOL-eligible — these are consumed at the published infrastructure rate regardless of the customer's licence model. Operating system licences (Oracle Linux on the Exadata infrastructure) are included in the infrastructure subscription. Database@Google Cloud does not currently support Standard Edition 2; the BYOL rules are Enterprise-Edition-only.

The pricing benchmark — what the unit economics look like

The unit prices above are indicative benchmarks from 2026 customer engagements; actual published rates vary by region, configuration shape, and the customer's Universal Credits commitment level. The pricing list rate is materially higher than the negotiated rate available through Universal Credits commitment structuring — the standard 8 – 22% Universal Credits discount range applies to Database@Google Cloud consumption as it does to native OCI consumption. For the negotiation framework, see Oracle OCI negotiation strategy.

The BigQuery integration — what changes for analytic workloads

The strategic differentiator on Database@Google Cloud is the proximity to BigQuery. Most enterprise Oracle Database deployments support transactional workloads that historically required a separate analytic store for reporting, business intelligence, and data science workloads. The data movement between Oracle Database and the analytic platform — through Oracle GoldenGate, ETL pipelines, or batch export — incurs cross-region latency, egress charges, and operational complexity. Database@Google Cloud collapses that movement into intra-region private connectivity.

The integration patterns supported in 2026 cover BigQuery direct read from Oracle Database tables (through the BigQuery Omni / BigLake connector framework), GoldenGate streaming replication into BigQuery, Vertex AI direct training on Oracle Database vector embeddings (the Oracle 23ai AI Vector Search integration with Vertex AI native vector indexes), and the standard Dataflow ETL patterns at low intra-region latency. The architectural net effect: workloads that previously required Oracle Database plus a separate analytic warehouse stack can run on Database@Google Cloud with BigQuery serving the analytic layer at materially lower total cost.

For the broader Oracle 23ai AI vector context, see Oracle Database 23ai AI Vector Search licensing.

The audit and compliance position

Oracle audit liability on Database@Google Cloud runs between the customer and Oracle Corporation under the Oracle Master Agreement, exactly as it does on any other Oracle deployment. The Database@Google Cloud commercial structure does not transfer audit liability to Google Cloud. What does change is the operational surface area Oracle LMS can inspect: the Database@Google Cloud environment is managed by OCI operations, which removes some customer-managed infrastructure forensics from the audit perimeter.

Specifically: the underlying Exadata infrastructure (storage cells, hypervisor configuration, platform-level options usage) is not a customer-managed inspection target. The deployed OCPU count, the Database options usage, and the RAC deployment are still measurable by Oracle through the OCI tenancy reporting and are still subject to standard Oracle audit mechanics on the BYOL portion of the consumption.

The compliance gap risk on Database@Google Cloud is materially lower than self-managed Oracle on Google Compute Engine (where USMM script execution against customer-managed GCE instances drives the LMS audit). It is not zero, and the standard audit defence framework still applies. For the broader audit context, see the Oracle audit defence master guide and audit risk in Oracle Database@Hyperscaler deployments.

"The Oracle-on-Google narrative was historically a stand-off — Oracle would not certify Google Cloud for Oracle workloads beyond limited Authorised Cloud Environment scope. Database@Google Cloud rewrites the relationship. The pricing and BYOL rules are settled; the audit position is materially better than self-managed Oracle on GCE; the BigQuery integration is the real story."

The architecture decision — when Database@Google Cloud is the right answer

Use Database@Google Cloud when

• The customer's analytic stack is BigQuery and the workload requires Oracle Database integration with BigQuery, Vertex AI, or the broader Google Cloud data services.
• The workload requires Oracle Real Application Clusters, Exadata performance features, or Oracle Autonomous Database — none of which are supported on Google Compute Engine self-managed Oracle deployments.
• The customer carries significant Oracle Database Enterprise Edition licence inventory (ULA exit, right-sized estate) that benefits from BYOL pricing on a managed Exadata service.
• The customer's Google Cloud commercial commitment is material enough to procure through Google Cloud Marketplace and consume against the existing CUD position.
• The workload is mission-critical with stringent recovery-time and recovery-point objectives benefiting from the Oracle Maximum Availability Architecture characteristics of Exadata.

Use self-managed Oracle on Google Compute Engine when

• The customer requires Oracle Database versions or configurations not supported by Database@Google Cloud (older legacy versions, bespoke patching cycles).
• The deployment is small-scale and the Database@Google Cloud Exadata minimum infrastructure cost is disproportionate to the workload.
• The customer accepts the materially higher audit exposure of self-managed Oracle on hyperscaler infrastructure and has the inventory governance to defend the BYOL position.

An anonymised case study — financial services Oracle plus BigQuery rationalisation

A North American financial services enterprise operated a 180-processor Oracle Database Enterprise Edition deployment supporting the trading, settlement, and risk management application stack, alongside a 600-slot BigQuery analytic environment supporting regulatory reporting and quantitative analysis. The architecture carried persistent operational pain: cross-region latency between the on-premise Oracle Database and BigQuery introduced 4 – 6 hour latency in regulatory reporting workflows, and the data movement consumed approximately $480k per annum in egress charges plus operational support overhead.

The architecture decision evaluated three options: self-managed Oracle on Google Compute Engine (rejected on RAC requirement and audit exposure), Oracle Database@AWS with cross-cloud connectivity to BigQuery (rejected on cross-cloud latency), and Oracle Database@Google Cloud with native BigQuery integration (selected on technical fit and intra-region performance). The Database@Google Cloud deployment used the customer's existing 180 processor licences against the BYOL pricing, eliminating the licence-included subscription premium.

The Oracle commercial engagement structured a 36-month Universal Credits commitment of $5.4M ($1.8M per annum) covering the Database@Google Cloud consumption. The Universal Credits commitment delivered a 19% discount against the on-demand rate and generated Support Rewards capture of approximately $450k per annum against the on-premise residual support stream (Oracle E-Business Suite supporting the back-office functions, retained on-premise). The Google Cloud Marketplace billing route was chosen to consume against the customer's existing Google Cloud CUD position, simplifying internal procurement.

The buyer-side defence challenged three Oracle scope-expansion attempts during the deal structuring: the proposed bundling of Java SE Universal Subscription into the Universal Credits commitment (declined as out-of-scope), the proposed migration of EBS to Oracle Fusion Cloud as a Universal Credits add-on (declined pending separate evaluation), and the proposed audit-waiver only for the migrated Database scope rather than the full residual estate (re-scoped to cover both). The resulting commercial position carried $1.2M of annual savings against the pre-engagement combined Oracle support and BigQuery egress spend, plus three years of contractual audit waiver across the Database scope.

The four buyer-side moves on Database@Google Cloud

Move 1 — Force the BigQuery integration into the technical fit assessment. The Oracle account team will lead with Database@Google Cloud as a generic Database@Hyperscaler offering. The buyer-side framework should evaluate the BigQuery integration value separately — the analytic workload offload from Oracle Database to BigQuery, the cross-region egress elimination, and the operational simplification — and price the value of that integration into the commercial comparison against alternatives.

Move 2 — Benchmark Universal Credits against Google Cloud Marketplace. The two procurement routes deliver materially different commercial mechanics — Universal Credits captures Support Rewards on the on-premise residual; Google Cloud Marketplace consumes against the existing CUD commitment. The right route depends on the customer's specific Oracle support spend and Google Cloud commitment position. Quote both.

Move 3 — Lock the on-premise support cap as part of the deal structuring. Most Database@Google Cloud deployments are partial migrations — a portion of the Oracle estate moves; a portion remains on-premise. Lock the support uplift cap on the residual on-premise scope as part of the Database@Google Cloud commercial event. The combined