Oracle Multicloud Strategy Accelerates: Industry Implications of Cross-Cloud Interconnect GA, Exascale Database, and Regional Expansion

Oracle Multicloud Strategy Accelerates: Industry Implications of Cross-Cloud Interconnect GA, Exascale Database, and Regional Expansion

Introduction

From May to August 2026, Oracle disclosed a series of developments in succession on its official multicloud blog: Oracle Interconnect for AWS moved from limited availability to general availability (GA); Oracle AI Database@AWS and Oracle AI Database@Google Cloud introduced Exascale infrastructure and Exadata Exascale storage capabilities, respectively; and regional coverage expanded to 22 worldwide. These updates may appear scattered, but they point to the same proposition: when enterprise workloads are naturally distributed across multiple clouds, can database assets—regarded as the hardest to migrate—run across clouds without rearchitecting applications? For CTOs and cloud architects, this directly concerns the cost structure of cross-cloud networking, database deployment models, and the paths to achieving data residency and business continuity.

I. Background: A Concentrated Push Spanning Three Months

Oracle's core multicloud approach is not complex: run Oracle Database services on OCI infrastructure deployed near other cloud regions, and deliver them to customers through familiar toolchains and consolidated billing. This batch of announcements in summer 2026 represents a simultaneous expansion of this approach across both capability and geography.| Time | Event | Key Points | | --- | --- | --- | | May 15 | Oracle Interconnect for AWS Limited Availability | Announced by Nathan Thomas, Senior Vice President of OCI Product Management; the goal is to replace customers' self-built cross-cloud networks with managed connectivity | | May 20 | OCI GoldenGate GA on Oracle AI Database@Google Cloud | Can be provisioned directly in the Google Cloud console and paid for using Google Cloud commitment credits | | May 20 | Oracle AI Database@AWS Launches in São Paulo | Covers the South American market, with one availability zone initially | | June 17 | First Anniversary of Oracle AI Database@AWS Launch | Announced GA of Autonomous AI Database Serverless, Exascale infrastructure coming soon, expansion to 20 AWS regions, the MAA Platinum tier, and a long-term strategic collaboration agreement (SCA) | | June 23 | Adds Stockholm and San Jose | Total global regions reach 22 | | July 29 | Oracle Interconnect for AWS General Availability | First available in OCI Ashburn and AWS US East (N. Virginia), with more region pairs to follow | | August 12 | ExaDB-XS Launches on Oracle AI Database@AWS | Billed by ECPU and storage usage, lowering entry cost; sold through AWS Marketplace | | August 14 | Exadata Exascale Comes to Oracle AI Database@Google Cloud | Customers can provision Exadata VM clusters with Exascale storage |

Notably, this round of announcements is concentrated on AWS and Google Cloud. This cadence of first deeply integrating with selected hyperscale cloud providers suggests that Oracle's multicloud strategy is closer to replicating capabilities than to a broad rollout.

II. Technical Analysis: What Problem Does Each of the Three Solve?

1. Cross-Cloud Interconnect: Turning the Network from a Project into a ServiceIn the early days of multi-cloud, there were mainly two ways to connect two clouds: route traffic over the public internet, or build a self-managed encrypted tunnel. The former has clear exposure in security, availability, and capacity; while the latter keeps traffic off the public internet, it places the entire burden of procurement, configuration, and capacity management on the customer. In practice, enterprises also have to simultaneously coordinate two routing models that were not designed for each other, manage third-party contracts on both sides, and build a self-managed network before they can actually start doing business.

Oracle Interconnect for AWS aims to change exactly this layer. It provides private, high-speed, fully managed connectivity between OCI and AWS, uses IEEE 802.1AE MACsec encryption by default, adopts OCI’s unified and globally consistent connection pricing, does not charge data transfer fees, and is jointly supported by Oracle and AWS. In nontechnical terms: this is like building a dedicated expressway between two campuses, jointly operated by both parties, so enterprises no longer need to pave the road, buy the land, or maintain the road surface themselves.

2. Exascale: Decoupling Compute and Storage to Lower Exadata’s Entry Barrier

Traditional Exadata is more like an integrated appliance: compute and storage scale together at a fixed ratio, and once capacity planning deviates, you either waste capacity or hit limits. The key change with Exascale is to separate the two.

On the AWS side, ExaDB-XS is based on Oracle’s multi-tenant elastic cloud model. Customers can start with a small VM cluster, independently scale compute and storage, and pay only for the ECPU and storage actually used. It supports Oracle Database 19c and Oracle AI Database 26ai, and provides thin clone and redirect-on-write-based snapshot and cloning capabilities. On the Google Cloud side, customers can provision Exadata VM clusters with Exascale storage, flexibly scaling storage as database needs grow, while retaining the performance, availability, and reliability characteristics of dedicated Exadata.

For managers, the essence of this change is a shift in procurement logic: from buying enough capacity upfront to paying as you go and scaling as you grow, with more of the capital expenditure characteristics shifting toward operating expenditure.

3. OCI GoldenGate: Data Plane in Multi-Cloud ScenariosRunning databases across clouds makes data synchronization unavoidable. Now that OCI GoldenGate is generally available on Google Cloud, customers can directly provision this managed service in the Google Cloud console and pay with Google Cloud commitments. It provides low-latency change data capture (CDC) and real-time replication, supporting low-risk database migration, hybrid and multicloud architectures, improved availability, and near real-time analytics across Oracle and non-Oracle data sources.

CDC can be understood as a continuously updated change log: every data change in the source database is captured and synchronized to the target, rather than being moved in bulk during a batch window. This allows operations, analytics, and AI workloads to be built on continuously synchronized data.

III. Enterprise Impact Analysis

Cost structure. ExaDB-XS is billed by ECPU and storage usage, directly lowering the trial and entry barriers for Exadata; Exascale's independent scaling reduces the waste of reserving capacity for peak demand. Interconnect uses unified connectivity pricing and does not charge data transfer fees, making cross-cloud network spending closer to a predictable fixed item. It should be noted that total cross-cloud costs still need to be comprehensively calculated in combination with the billing rules on both ends; network is only one part of it.

Deployment model. For Oracle customers already running applications on AWS, no refactoring is the core selling point of this batch of updates: database services run on OCI infrastructure but are deployed close to AWS applications. Phased migration, distributed application architectures, and reduced reliance on the public internet are all directly actionable scenarios.

Operations and support. Consolidated billing, continued use of existing toolchains, and coordinated support interfaces between Oracle and AWS reduce organizational friction for cross-cloud teams. But the complexity of multicloud operations will not disappear because of this; it merely shifts from self-built networks and contract management to federated identity, monitoring, and fault localization.

Security and compliance. Default MACsec encryption and private links reduce the public exposure surface. Regional expansion is a direct response to compliance issues: Stockholm serves the data residency needs of the Nordic and European markets, San Jose is close to the technology and business clusters of the western United States, and São Paulo covers the South American market. For regulated industries, such regional choices often carry more decision weight than performance metrics.

IV. Market Competition Analysis

From a competitive landscape perspective, the defining feature of this batch of updates is differentiated competition. Oracle did not directly compete with hyperscale cloud providers for general-purpose compute at the IaaS layer; instead, it treats the database as a product delivered across clouds, allowing AWS and Google Cloud to gain more workloads while Oracle gains database consumption. This is more like a complementary alliance: the long-term strategic cooperation agreement (SCA) announced by both parties on June 17 further solidified this relationship. According to official disclosures, one year after Oracle AI Database@AWS launched, hundreds of customers are already running mission-critical workloads on it.

Potential beneficiaries include: enterprise customers with large amounts of Oracle database assets who want to keep their applications on other clouds; AWS and Google Cloud, because they host more enterprise-grade database and AI workloads; and channel partners and integrators operating around AWS Marketplace and Google Cloud committed budgets.

Those likely to come under pressure include: third-party service providers primarily engaged in self-built cross-cloud dedicated lines and network hosting, whose value proposition is diluted by managed connectivity plus unified pricing; and the narrative that business databases must be entirely rewritten as cloud-native databases—Exascale and dual-version support for 19c/26ai let more enterprises choose a gradual route of migrating first and modernizing later. Accordingly, cloud-native database vendors will face greater resistance to replacement when competing for Oracle’s existing workloads.

V. Industry Trend Observations

The focus of multi-cloud competition is shifting from connectivity to the data plane. Over the past few years, the engineering problem of multi-cloud was mainly network interoperability; but capabilities such as Exascale, GoldenGate, and native AI vector search show that the next phase of competition will be about how data flows across clouds and how it is used by AI.

The direction of data gravity is reversing. Traditionally, applications were moved next to the data; now database services are moved next to applications—the database runs on OCI infrastructure but is deployed close to AWS or Google Cloud regions. This cloud-in-cloud model may become the default migration path for enterprise legacy systems.

Sovereignty and regionalization are becoming product features. The successive launches in Stockholm, São Paulo, and San Jose show that regional coverage is no longer just latency optimization, but compliance infrastructure for data residency and business continuity.

The boundary between AI and databases continues to blur. From product naming to capability combinations (Autonomous AI Lakehouse, native AI vector search, the 26ai version), Oracle is embedding AI capabilities into the database layer rather than having enterprises build a separate vector retrieval and feature platform outside the database.These changes collectively point to one judgment: multicloud is evolving from a network architecture choice into a data architecture choice, and over the next five years, competition in cloud infrastructure will increasingly center on the portability of data services.

CloudTechDaily Insight

What is most worth noting about this batch of announcements is not any single feature, but that the unit of account in multicloud competition is changing. In the past, when enterprises evaluated multicloud, they looked at dedicated line bandwidth, egress traffic, and operations manpower; now what is being put on the table is the entry cost of databases (billed by ECPU and storage), the pricing method for cross-cloud connectivity (unified connection pricing, no data transfer fees), and whether data can be consumed by AI in place. When these elements are productized, multicloud decisions shift from a question of technical feasibility to a calculable question of finance and compliance.

For enterprise IT strategy, three points are worth incorporating into evaluation. First, cross-cloud databases are no longer the endpoint of a migration project, but can become a long-term operating state, and the criteria for architecture review need to be adjusted accordingly. Second, once the connectivity layer is managed as a service, the predictability of cross-cloud costs improves, but dependency also deepens—customers need to assess their degree of reliance on the two vendors' long-term collaborative relationship and joint support processes. Third, regional expansion brings compliance options rather than purely performance gains, and regulated industries should incorporate the regional list into data residency and continuity planning.

It must be acknowledged that this model still depends on the willingness of hyperscale cloud vendors to cooperate and on their product roadmaps. This round of disclosures focuses on AWS and Google Cloud, and coverage is not yet complete; the actual performance of joint support in fault localization and responsibility allocation also requires more production environment validation. Therefore, a more pragmatic approach is: use small-scale ExaDB-XS clusters to validate the performance and operational experience of mission-critical databases in cross-cloud environments, use Interconnect pilots to replace existing cross-cloud public networks or self-built links, and complete a dual check of the cost model and data residency before scaling up.

From a medium- to long-term perspective, databases as cross-cloud services are very likely, like managed databases back then, to move from an exception to the industry default configuration. Once leading database vendors complete this step, the pressure on other enterprises and cloud vendors to follow will quickly become apparent—this is the most far-reaching impact of this event on the cloud computing industry.

---

Reference source: Oracle official blog "Oracle Multicloud – What's News," https://blogs.oracle.com/cloud-infrastructure/oracle-multicloud-whats-new-blog