Oracle Database@Azure, @AWS, and @Google Cloud: The Buyer Guide

For two decades, the question for an Oracle estate was binary: run it yourself, or run it in Oracle's cloud. The Database@ family ends that binary. Oracle Database@Azure, Oracle Database@AWS, and Oracle Database@Google Cloud put genuine Oracle Exadata hardware, owned and operated by Oracle, inside the hyperscaler's own datacenters, a short hop from the applications, analytics platforms, and AI services your teams already use. The pitch is simple: keep the database on the platform Oracle builds for it, keep everything else where it already lives, and stop paying the latency and egress tax of stitching two clouds together over the public internet or even over a dedicated interconnect.

It is a genuinely good idea, and in many estates it is the right answer. But it is not automatically the right answer, and the three offerings are not interchangeable. They differ in maturity, in the services available, in region coverage, and in how the commercials flow through each marketplace. Native OCI remains cheaper and more complete for some workloads, and an interconnect architecture still wins in specific cases. This pillar guide walks through the whole decision as an independent advisor would, with links into the detailed articles in this cluster where you want to go deeper. It sits alongside our broader multicloud and hybrid workload practice, where these architectures get designed and run in production.

What the Database@ model actually is

Strip away the marketing and the model is precise. Oracle installs Exadata racks inside an Azure, AWS, or Google Cloud datacenter. Oracle owns the hardware, Oracle operates it, and the OCI control plane manages it: when you provision an Exadata Database Service VM cluster or an Autonomous Database through Database@Azure, you are using OCI services that happen to be running in a child site located inside someone else's building. Your database traffic to applications in that cloud travels over the hyperscaler's internal network, not across the internet and not across a metro interconnect between two separate cloud regions.

Three things follow from this design, and they shape every buying decision. First, the database platform is real Exadata, with the same RDMA fabric, smart storage offload, and RAC clustering you would get in an OCI region, so performance characteristics carry over rather than being approximated. Second, the operational model is Oracle's: patching of the infrastructure, hardware lifecycle, and the platform layer are Oracle's responsibility, while your team or your managed services partner runs the databases themselves. Third, the commercial wrapper belongs to the hyperscaler. You buy through the Azure Marketplace, the AWS Marketplace, or the Google Cloud Marketplace, the spend lands on your existing cloud bill, and in most negotiated agreements it counts toward your committed spend with that hyperscaler.

That last point deserves emphasis because it is often the deciding factor in practice. Enterprises with an Azure consumption commitment or an AWS enterprise discount agreement have money they must spend anyway. Database@ lets the Oracle estate draw down that commitment instead of adding a separate Oracle cloud bill, which can make the internal business case dramatically easier even before any technical argument is made. We unpack how to model this properly in building the business case for Database@.

Why Oracle built it, and why the hyperscalers agreed

Database@ exists because of data gravity. The large enterprise application estate moved to Azure and AWS over the past decade, and increasingly to Google Cloud for analytics and AI, but the Oracle databases underneath those applications often stayed on premises or moved reluctantly. Every architecture that split the application from its database across two clouds paid for it in latency, egress charges, and operational complexity. Oracle could not pull the applications back, so it moved the database to the applications.

For the hyperscalers, the calculus was equally pragmatic. Oracle databases anchor enormous estates, and whichever cloud hosts the database tends to win the surrounding workloads. Hosting Oracle's hardware inside their datacenters keeps those estates, and the marketplace route means the revenue flows through their agreements. Everyone gets paid, and the customer gets a single network, a single bill, and the database platform Oracle actually engineers for. Understanding these incentives matters for buyers, because it explains both why the offerings exist and why the commercial terms are usually negotiable: all three parties want the deal to happen.

The three offerings: what is the same and what differs

The core proposition is identical across all three clouds: Oracle operated Exadata infrastructure inside the partner datacenter, OCI control plane underneath, purchase through the partner marketplace. The differences are in maturity, service breadth, region strategy, and integration depth, and they are material enough that the choice of cloud often decides the choice of offering rather than the other way around.

Oracle Database@Azure

Database@Azure was first to market and remains the most mature of the three, with the broadest service catalog and the deepest integration work. Exadata Database Service and Autonomous Database are available, and the Exascale tier has extended the entry point downward so that mid sized estates can get Exadata economics without committing to dedicated racks; we cover that shift in detail in Exadata Exascale on Azure. Identity integrates with Microsoft Entra ID, metrics and logs can surface in Azure native tooling, and provisioning is increasingly possible from the Azure portal itself. The networking model, including how the delegated subnet design works and where its constraints bite, is the subject of Database@Azure networking explained, and the full picture of the offering is in our complete guide to Oracle Database@Azure.

Oracle Database@AWS

Database@AWS arrived later and has been catching up on service coverage and regions since. The architecture follows the same pattern, with Oracle managed Exadata inside AWS Availability Zones and integration into AWS constructs like VPC peering to the database network, CloudWatch visibility, and IAM aligned access patterns. For AWS centric estates the comparison that matters most is usually not against Azure but against what AWS itself offers: RDS for Oracle and self managed Oracle on EC2 both have real but bounded capabilities, and we draw that line carefully in Database@AWS versus RDS for Oracle. The commercial mechanics, including how marketplace billing interacts with enterprise discount commitments, get a dedicated treatment in Database@AWS pricing and commercials, and the full service walkthrough is in our complete guide to Oracle Database@AWS.

Oracle Database@Google Cloud

Database@Google Cloud completes the set and tends to appeal to a different buyer: organizations whose center of gravity is analytics and AI rather than transactional application hosting. The draw is putting the Oracle system of record adjacent to BigQuery, Vertex AI, and the Google data stack, so that operational data feeds analytics pipelines without a cross cloud transfer in the middle. Service coverage and region availability have expanded steadily, though the offering is generally the youngest of the three in any given geography, so checking the current marketplace listing for your target region matters more here than elsewhere. Our complete guide to Oracle Database@Google Cloud covers the offering end to end.

Comparing the three offerings and native OCI

The honest comparison includes a fourth column, because native OCI is always an option and is sometimes the better one. Region counts and service lists change quarter by quarter, so treat the table as a structural comparison and verify the current state against Oracle's published region list and each marketplace listing before you commit.

The pattern in the last two rows is the heart of the buying decision. Database@ is a convenience premium over native OCI: you pay somewhat more per unit of the same Exadata capacity in exchange for adjacency to your applications and a marketplace billing route. Whether that premium is worth paying depends almost entirely on where your applications live and how much your committed spend agreements are worth to you. The detailed head to head for the most common case is in Database@Azure versus native OCI, and region by region availability across all three offerings is tracked in Database@ regions and availability.

How buying through the marketplace actually works

The purchase route is one of the least discussed and most consequential parts of the model, so it is worth spelling out. You do not sign a new contract with Oracle to buy Database@. You transact through the hyperscaler marketplace, typically as a private offer negotiated with both vendors at the table, and the charges appear on your existing Azure, AWS, or Google Cloud invoice. Behind the scenes the hyperscaler settles with Oracle, but from your side there is one bill, one procurement workflow, and one set of payment terms you have already negotiated.

The committed spend interaction is where the money moves. Most large Azure agreements include a consumption commitment, often discussed under the MACC label, and most large AWS agreements include an EDP style commitment with discount tiers tied to total spend. Marketplace purchases generally count toward these commitments, subject to the rules in your specific agreement, which means a Database@ purchase can simultaneously fund the Oracle estate and protect a discount tier you were at risk of missing. That double effect is why procurement teams sometimes champion Database@ harder than the database team does. The caution is that the rules differ by agreement and change over time: what fraction of a marketplace transaction counts, whether private offers qualify, and how renewals treat the spend are all contract specifics, so have your cloud commercial owner confirm them against the current agreement rather than assuming. The modeling approach, including how to compare a commitment funded Database@ purchase against a Universal Credits funded native OCI estate on equal terms, is worked through in our business case article linked above, and the ongoing discipline of keeping two control planes and two bills honest is covered in our cost governance article.

The decision criteria that actually matter

Across the assessments we run, the same six factors decide nearly every Database@ evaluation. Most buyers weight them in roughly this order, though the licensing factor jumps to the top whenever an Oracle agreement renewal is near.

Where the applications live. This is the dominant factor. If the application tier, integration layer, and analytics stack are committed to one hyperscaler, the database wants to be in the same cloud, and Database@ in that cloud is the natural shortlist leader. If the estate is genuinely split across clouds, or mostly still on premises, the answer is less obvious and native OCI deserves a harder look.

Latency tolerance. Chatty applications, two phase commits, and high frequency OLTP punish distance. Database@ removes the distance entirely. But plenty of workloads, batch processing, reporting, and most modern service oriented designs tolerate a few milliseconds without complaint, and for those an interconnect architecture at native OCI prices can be the smarter trade.

Region availability. Database@ exists only where Oracle has installed hardware, which is a subset of each hyperscaler's regions and a subset of OCI's own footprint. If your data residency requirement points at a country where the offering has not landed, the decision is made for you. Oracle publishes the current region list for each offering; verify it early, not after the architecture is drawn.

Licensing posture. BYOL versus license included changes the economics of every option in this guide, and the rules about how existing licenses, ULAs, and support streams map onto Database@ environments have traps that surface at audit time. We cover the specifics in licensing for Database@ multicloud, and for anything contractual we point clients at genuinely independent licensing counsel.

Commercial commitments. If you hold a large Azure or AWS commitment, Database@ spend that draws it down is money you were going to spend anyway. If you hold a large Oracle Universal Credits commitment instead, the gravity pulls the other way, toward native OCI. Map the actual agreements before comparing list prices, because the agreements usually matter more.

Operations ownership. Database@ gives you Oracle operated infrastructure but not an operated database: backups, patching windows at the database layer, performance management, and monitoring across two control planes remain your problem. Day two reality across the OCI and hyperscaler tooling is the subject of operating Database@ in production, and it should be costed into the comparison rather than discovered after go live.

A decision framework

Here is the sequence we use in assessments, in the order that eliminates options fastest.

Disaster recovery across clouds

Database@ opens a DR pattern that did not exist before: a primary database in one hyperscaler and a standby in another, or in a native OCI region, all on the same Exadata platform with Data Guard between them. Done well, this gives genuine cloud provider diversity for the crown jewel data without rewriting anything. Done casually, it doubles cost and halves clarity, because every failover now crosses an organizational boundary as well as a network one. The patterns that work, including the pragmatic choice of a native OCI region as the standby site to keep the second copy cheap, are laid out in multicloud DR with Database@.

Two practical notes from estates that have built this. First, test the failover path under realistic conditions before you depend on it, because the replication link between sites crosses networks owned by different parties, and the observed lag under load is the number that matters, not the theoretical one. Second, keep the DR site on the same licensing model as the primary where you can, because mixing BYOL and license included across a Data Guard pair creates accounting questions that are easier to avoid than to answer at audit time.

Common buyer mistakes

The same handful of errors show up in most troubled Database@ programs, and all of them are avoidable at evaluation time.

Buying the premium without the adjacency benefit. Putting a database on Database@Azure when its applications are on premises or in another cloud pays the colocation premium for nothing. The model only earns its price when the workloads it serves are actually in the same cloud.

Assuming the three offerings are equivalent. Teams choose the cloud first and assume the Oracle offering inside it matches what a colleague described in another cloud. Catalogs, regions, and integration depth differ; verify against the current listing for your cloud and region.

Ignoring the OCI control plane. Underneath the marketplace wrapper, this is OCI. Your team needs OCI skills, OCI identity design, and OCI cost reporting alongside the hyperscaler equivalents. Pretending otherwise produces the two control plane confusion that multicloud cost governance exists to untangle, with spend visible in one console and resources managed in another.

Treating licensing as a checkbox. BYOL assumptions that were true on premises do not automatically hold inside a Database@ environment, and the cost difference between the licensing models is large enough to flip the business case.

Skipping the migration plan. The platform decision gets months of attention while the path from the current estate, with its downtime budgets, version gaps, and character set issues, gets a slide. The realistic options, from Data Guard switchovers to ZDM and GoldenGate, are mapped in migration paths to Database@.

When native OCI or an interconnect is the better answer

An independent guide has to say this plainly: a meaningful share of the estates we assess should not buy Database@ at all.

Native OCI wins when the workload does not need to sit next to a hyperscaler application estate. Databases serving on premises users, standalone data platforms, estates already committed to Oracle Universal Credits, and teams that want the newest Oracle services first are all usually better served, at lower unit cost, in an OCI region. OCI also remains the only home for some capabilities and the broadest sovereign and government footprint.

The interconnect pattern wins when latency tolerance is moderate and cost discipline is strict. Oracle and Microsoft operate a dedicated interconnect between OCI and Azure in many metros, which we cover in our guide to the OCI Azure Interconnect, and equivalent partner based connectivity exists toward AWS, examined in interconnecting OCI and AWS. With the database at native OCI prices and a link with low latency to the applications, the total cost frequently undercuts Database@ for workloads that tolerate a few milliseconds. The trade is real, two clouds to govern and a network boundary to engineer, but for reporting, batch, and most service architectures it is often the rational choice.

There is also a sequencing argument worth weighing. Nothing about an interconnect architecture forecloses Database@ later: a database that lands in a native OCI region today, connected to its applications over the interconnect, can move into a Database@ site in the same metro when the latency case or the commercial case firms up, and the migration between two Exadata homes is far simpler than the original move from on premises. Teams under time pressure sometimes get better results by landing on native OCI first and deferring the Database@ decision until the application estate has settled, rather than trying to make both calls at once.

Staying on premises, finally, is not a failure. An Exadata Cloud@Customer or a well run on premises estate with years of depreciation left can be the right answer for another cycle, especially when the application estate it serves has not moved either. The point of a buyer guide is the decision, not the purchase.

Bringing it together

Database@Azure, Database@AWS, and Database@Google Cloud are the most significant change to Oracle database hosting in years: real Exadata, inside the cloud your applications already use, bought through the marketplace agreement you already hold. The model is sound, the engineering is genuine, and for application estates committed to a single hyperscaler it is frequently the right call. But the three offerings differ in maturity and coverage, the premium over native OCI is real, and the licensing and commercial mechanics reward buyers who do the analysis before the order form. Work through the framework above, verify regions and catalogs against current listings rather than recollection, and keep native OCI and the interconnect patterns honestly on the table until the numbers rule them out.

If you want that analysis done with someone who has run it before, this is exactly what our assessment work covers: we evaluate the estate, model the options, and either run the program or hand you the plan, on a fixed project fee, a managed monthly retainer, or an optimization fee paid only on verified savings. The independent view tends to pay for itself before the first contract is signed.