Oracle’s multicloud strategy moved from incremental rollout to visible scale this month as Big Red extended Oracle Database@Google Cloud into new Google regions while continuing a rapid global expansion of Oracle Database@Azure — and, crucially, shipped multiple AI‑centric database services that change how organisations plan latency‑sensitive analytics, disaster recovery, and cloud procurement.
Oracle’s “Database@” program places Oracle‑managed database services — including Exadata, Autonomous Database, and new lower‑cost virtualized options — on Oracle Cloud Infrastructure (OCI) hardware that is physically located inside other hyperscalers’ datacenters. The goal is pragmatic: keep Oracle’s enterprise database engine and operational model intact while letting customers run applications, analytics, and AI in the hyperscaler environment they prefer. The recent announcements add new regions, make new database SKUs generally available, expand disaster‑recovery capacity, and open a partner resale route through hyperscaler marketplaces. These moves were described by Oracle and its hyperscaler partners in coordinating announcements and public statements.
The net effect: customers get more in‑region choices for performance and compliance, additional deployment models (virtualized Exadata on exascale infrastructure and a pay‑as‑you‑go Base Database Service), and native integrations to hyperscaler AI and analytics surfaces such as Google’s Gemini/BigQuery/Vertex AI and Microsoft’s Fabric/Power BI/Entra ecosystems. Oracle frames the expansion as simplifying multicloud deployments and accelerating modernization; hyperscalers emphasise low latency for "AI near the data."
Key bullets:
That said, the promise carries caveats: regional SKU parity, cross‑cloud operational complexity, license and cost management, and rigorous validation of latency and DR behaviours remain prerequisites to success. Enterprises should treat this as a powerful set of options rather than a turnkey panacea: perform proof‑of‑value, insist on written SKU/SLA commitments, and adopt staged migration patterns that preserve rollback options.
The technical and commercial building blocks are now in place for Oracle’s multicloud model to move from early production to broad enterprise adoption — but successful outcomes will depend on disciplined testing, clear commercial terms, and partners capable of operating across Oracle and hyperscaler ecosystems. For IT leaders balancing legacy Oracle estates with modern AI ambitions, these announcements significantly expand the toolkit. The next step is careful, evidence‑based migration work that proves the theory in each organisation’s own operational reality.
Source: Data Center Dynamics Oracle adds new regions to multicloud offering with Google and Microsoft; adds new capabilities
Background / Overview
Oracle’s “Database@” program places Oracle‑managed database services — including Exadata, Autonomous Database, and new lower‑cost virtualized options — on Oracle Cloud Infrastructure (OCI) hardware that is physically located inside other hyperscalers’ datacenters. The goal is pragmatic: keep Oracle’s enterprise database engine and operational model intact while letting customers run applications, analytics, and AI in the hyperscaler environment they prefer. The recent announcements add new regions, make new database SKUs generally available, expand disaster‑recovery capacity, and open a partner resale route through hyperscaler marketplaces. These moves were described by Oracle and its hyperscaler partners in coordinating announcements and public statements. The net effect: customers get more in‑region choices for performance and compliance, additional deployment models (virtualized Exadata on exascale infrastructure and a pay‑as‑you‑go Base Database Service), and native integrations to hyperscaler AI and analytics surfaces such as Google’s Gemini/BigQuery/Vertex AI and Microsoft’s Fabric/Power BI/Entra ecosystems. Oracle frames the expansion as simplifying multicloud deployments and accelerating modernization; hyperscalers emphasise low latency for "AI near the data."
What changed: regions, capacity and new SKUs
Google Cloud: three new regions now live, nine more planned
Oracle Database@Google Cloud is now live in eight Google Cloud regions across Asia‑Pacific, Europe and North America with the most recent additions being Australia‑Southeast 2 (Melbourne), NorthAmerica‑Northeast1 (Montreal) and US Central 1 (Iowa). Oracle also says it has expanded capacity in key disaster‑recovery regions — notably Ashburn (US East) and London (UK South) — where additional Exadata capacity is intended to improve resiliency for mission‑critical workloads. Oracle’s official announcement and Google’s commentary confirm the region list and the 12‑month roadmap that includes multiple additional locations such as Sydney, Tokyo, Mumbai, Delhi, Milan, Toronto and São Paulo.Key bullets:
- Live Google regions (current): Ashburn (US East), Salt Lake City (US West), London (UK South), Frankfurt (Germany Central), Tokyo (Asia‑Northeast), plus new Melbourne, Montreal, and Iowa regions.
- Additional Google regions planned within 12 months: Mexico City, Sydney, Osaka, Mumbai, Delhi, Milan, Turin, Toronto, São Paulo (Oracle’s regional roadmap lists nine planned additions).
- Disaster recovery capacity increases planned for Ashburn, London and other major hubs to support cross‑region DR and high‑availability setups.
Microsoft Azure: broad footprint and ongoing rollouts
On the Microsoft side, Oracle Database@Azure continues its aggressive regional expansion with Oracle reporting availability in 28 Azure regions globally, and five more regions planned over the next 12 months. The current Azure footprint spans North America, EMEA, APAC and the Middle East, and includes regions such as Australia East, Brazil South, Canada Central and East, Central India, multiple US regions, Japan, the UK, UAE and several West US variants. This larger Azure footprint reflects an earlier phase of the same multicloud strategy and is advancing in parallel with the Google program.What the new capabilities actually are
Oracle Exadata Database Service on Exascale Infrastructure — now generally available for multicloud
Oracle has declared Oracle Exadata Database Service on Exascale Infrastructure generally available in the multicloud context. This offering is a virtualized Exadata deployment designed to lower the entry point to Exadata performance and provide more flexible, pay‑as‑you‑grow economics while preserving Exadata optimisations (RDMA I/O, storage offload, etc.). Oracle positions Exascale as a lower‑cost, easier‑to‑scale path for customers who need Exadata‑class performance but prefer smaller initial commitments. Both Oracle’s release and independent reporting confirm GA in the multicloud offerings.Oracle Base Database Service — lifecycle automation and pay‑as‑you‑go
The Oracle Base Database Service is now generally available as a lifecycle‑managed, virtualized database tier with pay‑as‑you‑go pricing. It brings automated provisioning, patching, Oracle APEX low‑code tooling, and independently scalable compute and block storage to multicloud customers who want to avoid the operational overhead of full Exadata while retaining Oracle Database compatibility. Oracle’s materials describe Base Database Service as intended for a broad mix of dev/test and production workloads.Oracle Autonomous AI Lakehouse — an AI‑first lakehouse
Oracle has also generalised the Autonomous AI Lakehouse, which pairs Oracle Autonomous AI Database technologies with open data table formats (Apache Iceberg) to drive cross‑platform AI and analytics. The lakehouse is positioned as an enterprise AI data plane that can interoperate with hyperscaler analytics and ML tooling (Google’s BigQuery/BigLake and Vertex AI are explicitly mentioned in Oracle’s messaging for the Google integration). The aim is to reduce ETL friction for retrieval‑augmented generation (RAG), vector search and large‑scale model training/inference that need consistent, governed data across transactional and analytic stores.Partner and marketplace changes — resellability and private offers
Both Oracle and the hyperscalers are pushing commerce flexibility. Oracle says partners can now offer Oracle Database@Google Cloud via marketplace channels and that Microsoft partners can resell Oracle via private offers in the Azure Marketplace provided they meet joint program requirements. This partner resale model is framed as an industry‑first route that reduces procurement friction and enables partners to deliver bundled migration, licensing, and managed services under a single marketplace private offer. The partner path could materially change procurement flows for enterprises accustomed to managing separate vendor contracts.Why this matters: three practical benefits
- Low latency for AI and analytics: colocating Oracle’s database tier physically inside Google or Azure datacenters reduces hops and improves round‑trip times between application/AI compute and the authoritative data store — a tangible advantage for real‑time RAG, vector search, agentic workflows, and operational analytics.
- Simpler procurement and licensing: Marketplace purchases, pay‑as‑you‑go SKUs and BYOL options let customers reuse existing commercial entitlements and keep procurement consolidated under the hyperscaler where they already spend.
- Preservation of enterprise Oracle capabilities: Oracle advertises full feature parity for key enterprise primitives — RAC, Data Guard, GoldenGate, and MAA levels — which is central to convincing large customers to move without application rewrites. Independent confirmations note that feature parity is a principal selling point, though availability of specific SKUs can vary by region and should be checked per deployment.
Technical analysis and operational implications
Networking and latency: the reality behind the marketing
Private cross‑cloud interconnects (OCI FastConnect paired with Azure ExpressRoute, or Google/OCI cross‑cloud interconnect) are the technical backbone of the multicloud pitch. These provide predictable latency and higher throughput than internet paths, and Oracle has made low‑latency figures part of its government‑targeted messaging. In practice, measured latency and throughput are site‑specific and depend on local network architecture, colo layouts, and the exact interconnect topology chosen. Architects should always validate the end‑to‑end path with real workload testing — synthetic network metrics alone don’t prove application performance at scale.Disaster recovery and cross‑region replication
Oracle has introduced cross‑region disaster‑recovery for Autonomous Database Serverless in the Google integration and has explicitly doubled capacity in Ashburn and London to improve DR for the Google offering. These capabilities make active‑passive or active‑active DR topologies more feasible for regulated workloads. Still, DR complexity increases with multicloud — network recovery, failover automation across two vendor control planes, and replication consistency must be tested end‑to‑end before declaring production readiness.Consistency of feature sets across regions
“Available in region X” does not automatically mean all SKUs and features are present in that region. Exadata SKUs, single‑node vs. clustered options, Autonomous Database variants, or DR‑only footprints may be staged across different dates. Procurement and architecture teams must confirm exact SKU and SLA availability for each region and workload class. Oracle’s cloud pages and the hyperscalers’ region‑specific announcements are the canonical references for these SKU maps.Business, partner, and procurement implications
Channel economics and partner enablement
Allowing partners to resell Oracle through hyperscaler marketplaces changes the GTM calculus. Managed service providers (MSPs) and systems integrators can now bundle Oracle compute and database operations with Azure or Google billing, providing single‑stop procurement and unified private offers. For customers this reduces procurement friction; for partners it increases addressable services but also raises certification and compliance overhead (partners must typically hold both hyperscaler and Oracle partnership statuses). This trade‑off will influence how quickly partners adopt and propagate the new reseller model.Licensing: BYOL, pay‑as‑you‑go and private offers
Oracle continues to support Bring Your Own License (BYOL) and has added pay‑as‑you‑go variants for Autonomous Database. Private‑offer purchase flows in marketplaces allow enterprises to reuse existing commitments while reserving custom commercial terms. These options reduce the friction of migration finance but require careful license reconciliation — especially for enterprises mixing BYOL with marketplace purchases and private offers. Auditable license records and migration‑time audits should be part of any migration plan.Security, compliance and government workloads
Oracle’s multicloud model expressly targets regulated workloads through in‑region availability and interconnects that can support FedRAMP‑equivalent deployments when paired with government cloud regions. For U.S. government customers, Oracle has expanded its interconnects to include government regions and cited sub‑millisecond network figures for tightly coupled government pairings. Nonetheless, compliance must be validated end‑to‑end: identity mapping, key custody (Azure Key Vault or equivalent), audit log centralisation and cross‑cloud incident response processes must be engineered and independently audited.Risks, caveats and unanswered questions
- Feature parity is region‑dependent. Some Exadata SKUs, DR pairings or single‑node options may be staged, and not all regions will support the same set of capabilities at launch. Confirm SKUs and SLA in writing before migration.
- Operational complexity increases. Running Oracle operations and support across two vendor control planes requires mature runbooks, joint escalation paths, and clear OLA/SLA language—particularly for high‑availability and security incidents.
- Cost predictability and egress economics: marketplace purchases and private offers simplify procurement, but total cost of ownership depends on consumption patterns, data transfer volumes, and reserved vs on‑demand purchasing models. Proof‑of‑value tests should include cost modelling under expected loads.
- Vendor and partner readiness: the partner resale program lowers procurement barriers, but the quality and coverage of partner services will vary; evaluate partner references, joint certifications and SLA commitments closely.
Practical migration playbook for IT leaders
- Inventory and prioritise: classify applications by latency sensitivity, regulatory needs, and Oracle feature dependencies (RAC, Data Guard, GoldenGate).
- Region & SKU confirmation: for each workload target region, obtain written confirmation of the exact Oracle SKU, Exadata class, DR pairings and SLA.
- Network proof‑of‑value: build end‑to‑end tests that simulate production traffic, include cross‑cloud interconnects, and measure RTO/RPO under real workloads.
- License reconciliation: map on‑prem entitlements to BYOL and marketplace private‑offer options; secure written audit‑safe license transfer terms.
- Test DR and failover: validate automated failover, backup restore, and audit trail integrity across the multicloud control planes.
- Partner selection and runbooks: if using a partner, require joint escalation matrices, certified staff complements and documented SLAs prior to contract signature.
- Cost modelling and gating: run TCO scenarios across 12–36 months and set migration gates based on latency, security, and cost thresholds.
Competitive landscape and what hyperscalers gain
Hyperscalers benefit by hosting Oracle’s database tier: they keep higher‑value workloads — the ones with steady revenue and strong margins — inside their datacenter fabric while offering their AI/analytics layers as primary developer surfaces. For Oracle, multicloud preserves the installed base and drives OCI hardware density irrespective of the application plane. Customers gain flexibility but pay the complexity tax. This bargaining dynamic is central to the industry shift — hyperscalers want enterprise workloads, database vendors want to remain central to transactional and analytic data planes, and customers want both low latency and procurement simplicity.Final assessment and conclusion
Oracle’s latest wave of announcements materially improves the practical utility of its multicloud strategy. The combination of new Google Cloud regions, expanded Azure availability, GA of Exadata on Exascale Infrastructure, Oracle Base Database Service, and the Autonomous AI Lakehouse provide customers with a richer set of deployment choices — from low‑entry Exadata to AI‑ready lakehouse architectures. The partner resale and marketplace private‑offer changes reduce procurement friction and will accelerate adoption for organisations that prefer a single procurement and managed‑service path.That said, the promise carries caveats: regional SKU parity, cross‑cloud operational complexity, license and cost management, and rigorous validation of latency and DR behaviours remain prerequisites to success. Enterprises should treat this as a powerful set of options rather than a turnkey panacea: perform proof‑of‑value, insist on written SKU/SLA commitments, and adopt staged migration patterns that preserve rollback options.
The technical and commercial building blocks are now in place for Oracle’s multicloud model to move from early production to broad enterprise adoption — but successful outcomes will depend on disciplined testing, clear commercial terms, and partners capable of operating across Oracle and hyperscaler ecosystems. For IT leaders balancing legacy Oracle estates with modern AI ambitions, these announcements significantly expand the toolkit. The next step is careful, evidence‑based migration work that proves the theory in each organisation’s own operational reality.
Source: Data Center Dynamics Oracle adds new regions to multicloud offering with Google and Microsoft; adds new capabilities
