Oracle's MySQL HeatWave Lands on Azure, Claims 140× Aurora Query Speed

Oracle bets on database portability as multi-cloud exit strategy

Oracle made MySQL HeatWave generally available on Microsoft Azure this month and confirmed plans to bring the unified OLTP-plus-analytics engine to Google Cloud, completing a three-hyperscaler strategy that runs the same codebase natively on AWS, Azure, OCI, and soon GCP. The move gives enterprises standardizing on MySQL a credible way to shift database workloads across clouds without re-platforming — a direct challenge to Aurora's lock-in on AWS and an alternative to Snowflake's analytics-only cross-cloud model.

The buyer implication is clearer exit options and procurement leverage. If your organization runs MySQL at scale and has flagged concentration risk on a single hyperscaler, HeatWave creates a path to rebalance spend without duplicating database engines or retraining teams. Oracle claims HeatWave delivers up to 140× faster query performance than Amazon Aurora and 6.8× better price-performance than Redshift on TPC-H-style benchmarks. If those numbers hold in production tests of your workloads, they materially shift total cost of ownership calculations for mixed transactional and analytical databases.

Oracle's broader cloud business — including OCI and SaaS — reported $6.4 billion in revenue last quarter, up 20% year-over-year, with management citing multi-cloud traction as a growth driver. The company says HeatWave has thousands of customers globally across financial services, retail, and SaaS, though it does not break out adoption by individual cloud. The product competes directly with Snowflake Data Cloud, Databricks Lakehouse Platform, and single-vendor stacks like Aurora-Redshift on AWS or Azure SQL-Synapse on Microsoft's cloud.

Google extends cross-cloud networking to AWS and Azure workloads

Google Cloud expanded its Cross-Cloud Network service to manage security posture and traffic observability for workloads running on AWS and Azure, not just GCP. The service positions Google's network fabric as a control plane that sits above other hyperscalers, a different approach from AWS Cloud WAN or Azure Virtual WAN, which treat external clouds as endpoints. Google claims the service reduces inter-cloud latency by up to 35% compared to internet-based VPN peering, based on internal tests.

The practical impact is consolidation of networking and security tooling. Enterprises currently paying for separate SD-WAN products and cloud-native constructs on each hyperscaler can centralize on Google's fabric and potentially retire one or more tools. This shifts budget toward Google Cloud networking SKUs and reduces the operational complexity of maintaining separate policy engines per cloud. Gartner forecasts the global IaaS market reaching $253 billion by 2027, with over 70% of large enterprises using multiple public clouds for mission-critical workloads. Cross-Cloud Network targets this segment directly.

For buyers negotiating with AWS or Microsoft, using Google as the neutral interconnect fabric rebalances power and creates leverage. It also makes splitting an application across clouds more feasible by reducing egress costs and latency, which directly affects whether cross-cloud microservices architectures meet user experience SLAs. Google reports hundreds of enterprise customers using its cross-cloud networking and security offerings, including organizations in financial services and retail, though it does not provide named customer counts specific to Cross-Cloud Network.

The service competes with Cisco SD-WAN, Palo Alto Prisma SD-WAN, F5 Distributed Cloud, and the native multi-cloud networking constructs from AWS and Azure. Google's differentiation is positioning itself as the orchestration layer rather than one of the clouds being orchestrated.

What this means for multi-cloud infrastructure decisions

The Oracle and Google moves reflect a shift in how hyperscalers and platform vendors are competing for multi-cloud budgets. Oracle is betting that database portability — running the same MySQL engine natively on three clouds — reduces switching costs enough to pull workloads away from AWS and Azure. Google is betting that enterprises will pay for a neutral networking and security fabric that manages workloads across competitors' clouds.

Both strategies give enterprise buyers more negotiation leverage. A portable database layer makes it credible to threaten moving workloads during contract renewals. A cross-cloud control plane reduces the operational penalty of actually doing it. If your organization has been stuck in a single-cloud architecture because re-platforming databases or re-building network topologies was too expensive, these products change the cost structure of diversification.

The risk calculation also shifts. Running the same database engine across clouds simplifies disaster recovery and provides a realistic path to sovereign cloud requirements without duplicating heterogeneous engines and skills. A unified networking fabric reduces the chance that a misconfigured security policy on one cloud creates an exploitable gap. Both matter for board-level risk assessments where concentration on a single hyperscaler has been flagged.

What to watch

Test Oracle's performance claims against your actual workloads before committing. Benchmark numbers are directional, not predictive. If HeatWave's 140× query speed advantage over Aurora holds in production, it justifies a pilot. If it does not, it is noise.

Watch Google's Cross-Cloud Network pricing as it scales. The value proposition depends on whether centralizing on Google's fabric costs less than the sum of SD-WAN and per-cloud networking tools you are replacing. Request detailed TCO modeling before shifting budget.

Track how AWS and Microsoft respond. If Oracle's multi-cloud MySQL or Google's cross-cloud fabric gains traction, expect competitive pricing pressure on Aurora, Redshift, and Azure networking SKUs. That creates a window for renegotiation even if you do not switch.