Exadata Exascale Across AWS, Azure & Google Cloud: Where Is It Available?

On this page

1. 01 · The Question Every Architect Asks First
2. 02 · What Exascale Actually Is
3. 03 · Availability on OCI and Each Hyperscaler
4. 04 · How the Database@ Model Places Exascale Inside a Hyperscaler
5. 05 · How to Verify Availability for Your Region
6. 06 · Choosing a Region When Exascale Is Uneven
7. 07 · What Changes Between the Three Hyperscalers
8. 08 · Planning Checklist Before You Commit
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · The Question Every Architect Asks First

Planning brief · Exadata Exascale in multi-cloud

"Can we get Exascale in our cloud, in our region?"

It usually comes up in the first architecture workshop. The application team is committed to AWS, Azure or Google Cloud. The DBA team wants Exadata performance without paying for a full quarter rack. Someone has read that Exascale lets you start with a small VM cluster and pay only for what you use. The obvious next question is whether that option exists in the hyperscaler and region the business has already chosen.

The honest answer is: probably yes, but you have to check three separate things. Is the Database@ service live in that region? Does that region offer the Exascale form of Exadata, or only dedicated infrastructure? And does your hyperscaler account have the marketplace offer and quota needed to provision it? Getting any one of these wrong turns a two-week design into a two-month delay.

02 · What Exascale Actually Is

Answer: Exadata Exascale is Oracle's multi-tenant architecture for Exadata. Instead of renting dedicated database and storage servers, you get a VM cluster that draws compute and storage from a large shared pool of Exadata hardware, billed per ECPU and per gigabyte, with no separate charge for IOPS.

Traditional Exadata in the cloud, Exadata Database Service on Dedicated Infrastructure (ExaDB-D), gives you a whole set of physical database and storage servers. That is ideal for large consolidated estates, but the minimum entry point is significant. Exascale, sold as Exadata Database Service on Exascale Infrastructure (ExaDB-XS), keeps the Exadata software stack, including Smart Scan, storage indexes and RDMA-based data access, while letting Oracle pool the hardware across many tenants.

Oracle positions this as up to 95 percent lower minimum infrastructure cost than the dedicated service. The practical effect for architects is that Exadata becomes a sensible choice for a single departmental database, a dev and test fleet, or a new application that might grow, not only for the flagship ERP.

03 · Availability on OCI and Each Hyperscaler

Answer: As of late 2026, Exascale is generally available on OCI and on all three Database@ partnerships: Oracle Database@Azure (since March 2025), Oracle AI Database@Google Cloud, and Oracle AI Database@AWS (since 13 August 2026). Each partnership rolls Exascale out region by region, so coverage still differs.

The timeline matters because it explains the uneven coverage you will see in practice. OCI had Exascale first and has the widest footprint. Azure was the first hyperscaler to get it, so its Exascale regions are the most mature. AWS is the newest: at launch Oracle described availability starting in US East (N. Virginia), US West (Oregon) and EU Central (Frankfurt), with ExaDB-XS following the Database@AWS footprint as it expands. Google Cloud sits in between, and Oracle has continued to add Exascale capabilities there through 2026.

The figure below puts the four environments side by side. In every hyperscaler the pattern is the same: your application tier, an Oracle-operated Exadata site in the same data center, and OCI's control plane reaching in to build and patch it. Read the dates as a guide to maturity: the earlier a platform got Exascale, the more regions, quotas and runbooks you can expect to find.

Notice that none of the clouds is marked complete. Every partnership is still expanding, so the question is never just "does AWS have Exascale" but "does the specific AWS region next to my application tier have it today, and is it on the published roadmap if not".

04 · How the Database@ Model Places Exascale Inside a Hyperscaler

Answer: In every Database@ partnership, the Exadata hardware is physically installed in the hyperscaler's data center and operated by OCI, while you provision and pay for it through the hyperscaler's console and marketplace. Exascale adds a shared storage and compute pool behind your VM cluster.

This is why availability is region-specific. Oracle has to install Exadata racks and an OCI child site inside each hyperscaler region, connect that site back to an OCI parent region for the control plane, and wire it into the hyperscaler's own networking. For Exascale there is an extra step: the shared Exascale storage pool must be built out in that site before the ExaDB-XS service can be offered there.

The diagram below shows the layers you are actually depending on when you pick a region. The application tier lives in your hyperscaler network. The Exascale VM cluster and pooled storage live in the Oracle-operated site inside the same data center. The OCI parent region provides the control plane, backups and fleet tooling. A gap in any of the three layers is what makes a region "not available yet".

The blue connector is your data path: application to database over SQL*Net inside the same data center, which is what keeps latency low. The dashed red connector is the control plane, and the orange connectors carry encryption keys and backups to OCI. You provision from the hyperscaler console, but OCI's control plane in the parent region actually builds and patches the cluster. That split is why both Oracle and the hyperscaler publish separate availability lists.

05 · How to Verify Availability for Your Region

Answer: Check four things in order: the Oracle multicloud region list, the Exascale service in that region's console, your account's marketplace subscription, and your service limits. Only treat a region as available when all four line up.

Region tables in blogs, including this one, go out of date quickly. The reliable approach is a short verification routine you can rerun at the start of every project.

1. Read Oracle's multicloud region list. Oracle publishes, per partnership, which regions run the Database@ service and which Exadata offerings each region supports. Look for Exascale or ExaDB-XS explicitly, not just Exadata.
2. Open the provisioning flow in the hyperscaler console. In the target region, start creating an Exadata VM cluster. If the Exascale option is missing from the choices, the region does not offer it yet, whatever a slide says.
3. Confirm the marketplace subscription. Exascale is purchased through the hyperscaler marketplace (private or public offer). Make sure the subscription covers the Exascale SKU and is linked to the right billing account.
4. Check quotas and limits. New accounts often start with low ECPU and storage limits. Raise a limit request early, because it can take longer than the build itself.
5. Record the answer with a date. Put the verified status and date into your architecture decision record so the next reviewer knows how fresh it is.

06 · Choosing a Region When Exascale Is Uneven

Answer: Pick the region next to your application tier first, then check Exascale. If Exascale is not there yet, choose between waiting, starting on ExaDB-D or OCI, or placing the database in a nearby region. Never trade away application-to-database latency just to get the Exascale price point.

The whole value of the Database@ model is that the database sits in the same data center as the application. If you place the application in one region and the Exascale cluster in another to chase availability, you lose that advantage and add cross-region data transfer charges. The table below shows how teams usually resolve the mismatch.

The decision flow that follows combines the four verification checks with the fallback options. If any check fails, it ranks the alternatives by the rework you will face later, once Exascale reaches the region next to your application.

The pattern is clear. Starting on dedicated infrastructure in the right region protects latency and needs little rework, because a later move to Exascale stays inside the same Exadata software stack. Starting somewhere else is cheaper at small scale but almost always means a second migration once Exascale arrives where your application lives.

07 · What Changes Between the Three Hyperscalers

Exascale behaves the same at the database layer everywhere: the same Oracle Database releases, the same Exadata features, the same ECPU and storage billing logic. What differs is the surrounding platform. Each partnership integrates with a different identity system, network construct and set of native services, and each reached Exascale at a different stage of maturity.

Treat the shared column as your portability argument: SQL, PL/SQL, tooling and performance behaviour carry over between clouds. Treat the per-cloud columns as your due-diligence list, because identity federation, network peering and native service integrations are where the real per-cloud work happens. Later posts in this series cover each cloud's integration path in detail.

08 · Planning Checklist Before You Commit

Before you put Exascale in a design document for any hyperscaler, walk through this list with both the cloud team and the DBA team in the room:

1. Region pair. Confirm Exascale in the primary region and in the region you will use for disaster recovery. DR is where coverage gaps most often hide.
2. Database versions. Exascale launched with the newest Oracle AI Database release and has since added Oracle Database 19c support. Confirm the exact release updates offered on your platform and that your application is certified on them.
3. Sizing floor. Exascale lets you start small, but each VM cluster still has minimum ECPU and storage values. Confirm them for your platform.
4. Commercials. Decide between pay-as-you-go and committed spend, and check whether Oracle Support Rewards or existing licences (BYOL) apply in that marketplace.
5. Network design. Agree on the CIDR ranges for the database network early. Overlaps with existing VPCs or VNets are the most common reason a provisioning run fails.
6. Operating model. Write down who patches, who monitors and who handles backups. Oracle runs the infrastructure; your team still owns the databases.

Exascale removes the hardware entry barrier. It does not remove the need to check, region by region, that the service you designed for is the service you can actually buy.

09 · Key Takeaways

1. Exascale is now on every major cloud. OCI since 2024, Oracle Database@Azure since March 2025, Oracle AI Database@Google Cloud, and Oracle AI Database@AWS since August 2026.
2. Coverage is regional, not global. A cloud having Exascale does not mean your region has it. Database@ coverage and Exascale coverage are separate lists.
3. Verify in the console, not on a slide. Region list, provisioning flow, marketplace subscription and quotas must all line up.
4. Keep the database next to the application. Do not trade latency for an earlier Exascale start; pilot on ExaDB-D in the right region instead.
5. Check the DR region too. Disaster recovery is where availability gaps most often surprise teams late in a project.

10 · Frequently Asked Questions