Exadata Exascale on AWS: Oracle’s Answer to Hybrid Cloud Database Performance

For years, the conversation around Exadata has carried a quiet assumption: that this is the platform you graduate to when your database is already enormous, already mission-critical, and already budgeted accordingly. But the dedicated racks, the storage servers, the upfront footprint – all of it pointed one way. Exadata was the “destination for the few”, not the many.

That assumption just died. On August 13, 2026, Oracle made Exadata Database Service on Exascale Infrastructure (ExaDB-XS) generally available inside Oracle AI Database@AWS. And if you are a DBA who has ever wanted Exadata’s engine in a PaaS model without Exadata’s entry ticket, this is the announcement that changes your arithmetic.

That announcement deserves a word about why it matters at all, because the choice underneath it is the one every DBA has made before. If you are running serious Oracle workloads, you are not really deciding between Exadata and a generic cloud instance. A database on plain EC2 or RDS runs Oracle’s engine on infrastructure that is not designed for it. Exadata is the one platform where the database and the hardware were engineered together: intelligent storage servers that push filtering, aggregation, and vector work down to the storage layer, a dedicated RDMA interconnect between compute and storage, and an integrated software stack that treats your database as the center of the architecture. For the workloads that matter, that difference is measurable.

The problem was the price. A dedicated Exadata deployment starts at a multi-server rack, so organizations that wanted the PaaS had to commit to a substantial upfront investment before they could find out whether it fit. ExaDB-XS removes that gate. You get the same engineered platform – same storage intelligence, same interconnect, same software – with the granularity of a consumption-based service, starting at a handful of ECPUs and a few hundred gigabytes of smart storage.

What Exascale actually is

Before we talk about AWS, we need to be precise about the technology. At its foundation, Exascale is a software-defined storage and compute architecture that replaces the two core pillars of classic Exadata: Automatic Storage Management (ASM) and the fixed server/VM-to-disk-group binding. Where classic Exadata ties a set of dedicated database servers or virtual clusters to a set of dedicated storage servers, with ASM managing stripe-and-mirror disk groups on top, Exascale dissolves that rigid topology into two software-defined abstractions:

The Exascale pool is a shared, software-defined fabric of Exadata intelligent storage and compute servers. Multiple virtual machines, and many database instances draw from the same physical pool at once. The pool abstracts away the server-to-disk-group mapping that has defined Exadata operations for two decades.
The Exascale vault is the storage-side unit of that pool: a single logical namespace within the shared fabric that provides high redundancy per object, resource management, auto-scales online, and serves as the storage backend for one or more virtual machine clusters. There is no ASM disk-group planning, no capacity partitioning, no stripe-and-mirror geometry to agonize over.

Some of the goals for this architecture are:

Storage efficiency – redundancy is applied per object across the shared pool rather than per disk group, so capacity utilization is higher.
Simplified provisioning – no disk-group sizing, no storage-server addition, no ASM rebalancing. You request storage, it appears.
Exadata smart software performance at cloud economics – the same query offload, Smart Scan, and HCC that made Exadata fast are retained, but you pay for consumption rather than for a minimum hardware footprint.
Thin-clone economics – the shared, software-defined vault changes what non-production environments cost. Because storage is allocated per object in a common pool rather than carved into per-customer disk groups, space-efficient copies of a production database – and even clones that cross VM clusters – become a design feature of the platform instead of a capacity project. A development or test database pays for the changes it makes against production, not for a full copy of production itself. Combined with the ability to scale idle compute to zero, that is where the architecture, not just the price list, changes the economics of maintaining a proper dev and test stack.

The timeline explains the strategy. Exascale launched on-premises in 2024, then moved to OCI, then into the multicloud deployments, and now, with this announcement, it completes its run across the major hyperscalers (Exascale announcement).

How it lands inside AWS

“Oracle AI Database@AWS” is deliberately specific. This is not Oracle Database offered as a managed service sitting on top of AWS. It is Oracle Cloud Infrastructure (OCI) running natively inside AWS data centers – a cloud region living inside a cloud region, as Moor Insights analyst Matt Kimball has framed it (Oracle product page).

That architectural choice has practical consequences. It is why the Exadata instances you spin up here run in the same data centers as your Amazon Bedrock, your S3 buckets, and your Redshift clusters, and why the latency between them is measured in microseconds rather than milliseconds.

Procurement: you buy through AWS Marketplace, either as self-service Public Offers or negotiated Private Offers, and both License Included (Oracle Enterprise Edition plus every option and management pack) and Bring Your Own License (BYOL) are supported.

Provisioning is a four-step flow worth knowing cold, because the split of responsibilities is unusual the first time you see it:

Create an ODB network – a private, isolated network hosting the Oracle infrastructure in a single Availability Zone, with optional S3 backup and Redshift zero-ETL integration.
Create an Exascale Storage Vault.
Create an Exascale VM Cluster – minimum 8 ECPUs per VM and 300 GB of storage, your choice of 19c or 26ai, and your license type. You can even choose to have only 1 VM, but you would be missing RAC features, so I would recommend to set it up with at least 2 nodes.
Create the database itself from the OCI console (the “Manage in OCI” step).

The commitment math is the part that should make you pause. A dedicated Exadata infrastructure subscription carries a four-year minimum term. An Exascale virtual machine cluster and its storage vault carry a 48-hour minimum – you are billed for the infrastructure for a minimum of 48 hours, and by the second after that. Two days against four years is a different class of commercial risk, and it is why this announcement matters for the organizations that always wanted the engine and were priced out of the door

There is one more operational detail worth flagging because it changes how you plan multi-environment architectures. You can create additional VM Clusters and attach them to the same Exascale Storage Vault as your first cluster. It means you can build a production VM cluster and a development or test VM cluster that share the same underlying storage pool, which in turn enables snapshot clones between different virtual clusters.

Same engine, pooled delivery

The most important technical truth in this announcement is easy to overlook because it is stated so plainly. ExaDB-XS delivers the same Exadata performance, availability, and security features as the dedicated tier, just on shared, pooled infrastructure.

You get Oracle RAC. You get Smart Scan, the storage-layer query offload that pushes filtering, aggregation, and vector math down to the storage servers. You still get Hybrid Columnar Compression (HCC). You still get the RDMA-based smart storage fabric. None of the Exadata differentiation is watered down in the pooled tier.

Moving predicate filtering and aggregation into the storage layer is what has separated Exadata from generic block storage since the beginning. The newest expression of that idea is AI Smart Scan, which offloads AI Vector Search down to the Exadata storage tier as well. For anyone building retrieval-augmented generation on top of Oracle, that can be a key feature.

There is one thing I want to flag again because it quietly changes how teams work: instant thin cloning via redirect-on-write. You can create space-efficient copies of a production database for dev and test, and ten parallel development branches cost you the storage of ten databases’ worth of changes, not ten full copies.

The economics that scale to zero

ExaDB-XS is fully consumption-based. You pay for ECPUs and storage gigabytes actually consumed. Compute and storage scale independently, in small increments, so you are not forced to buy storage you do not need just to add a few ECPUs, or vice versa. Be clear about what “consumption-based” does and does not mean: in addition to the usage you actually run, there is an infrastructure line item for the virtual infrastructure that hosts your VM cluster, billed for a minimum of 48 hours and then per second. You are not asked to provision or commit to a dedicated rack of hardware before your first query – that is what makes the entry point genuinely low – but the bill is not purely what you consume. It is usage, plus the small infrastructure charge that keeps your cluster’s footprint reserved.

Active compute can scale all the way to zero (Oracle Exascale blog) when workloads are idle. Concretely, this works as follows: you set the enabled ECPUs of your VM cluster to zero, which shuts down all the virtual machines in that cluster. Your database files, configuration, and storage remain intact in the vault. When you scale the enabled ECPUs back up, the VMs boot again from their reserved physical allocation, ready to serve queries. IN that moment usage-based compute billing stops entirely while the cluster is down. However, the physically-reserved total ECPUs remain allocated on the underlying hardware, so the infrastructure-related line item persists. If you have ever maintained a non-production Exadata environment that sits idle for 16 hours a day, the savings on the usage line alone are substantial

On pricing, ExaDB-XS pricing on AWS is identical to ExaDB-XS pricing on OCI – the same per-ECPU-hour and per-GB-hour rates apply regardless of which hyperscaler hosts the infrastructure (AWS Database Blog). The Exascale-specific per-ECPU and per-GB rates are listed on Oracle’s Exadata-on-Exascale price list. Billing is per-second, with pay-as-you-go and Annual Universal Credits subscription models both available.

The barrier to Exadata has always been the minimum footprint. Dedicated infrastructure historically required a minimum of two database servers and three storage servers, provisioned up front, before you ran a single query. ExaDB-XS removes that barrier. Exadata is no longer something you size a project around; it is something you attach to a project and let it grow.

The multicloud completion

There is a pattern here that has been building for years, and the AWS announcement is the last piece of it.

Oracle’s play has been to embed OCI inside the other hyperscalers’ data centers rather than fight them from the outside. It started with Oracle Database@Azure in 2022, the first of its kind. Then Oracle Database@Google Cloud, announced in June 2024 and generally available in four US and EU regions. Then Oracle Database@AWS, disclosed by Larry Ellison at CloudWorld in September 2024 and brought to general availability in July 2025 in US East (N. Virginia) and US West (Oregon) (Oracle multicloud page).

What is new in August 2026 is that Exascale is now the common tier across all of them. On August 5 ExaDB-XS was available on OCI and in Oracle’s multicloud offerings on Microsoft Azure and Google Cloud; the August 13 AWS GA completes the set across all three hyperscalers. Google Cloud’s own documentation confirms that Exascale Infrastructure – VM clusters and storage vaults – is a supported product inside Oracle Database@Google Cloud (Google Cloud docs).

Why does this matter to a customer? Because it changes the negotiating position and the architecture freedom at the same time. Oracle’s stated goal, in Ellison’s phrasing, has been to let customers “use the Oracle Database anywhere and everywhere”. With Exascale now spanning OCI, AWS, Azure, and Google Cloud, that is no longer an aspiration. It is the product line.

The portfolio on AWS itself is now complete in a meaningful sense: ExaDB-XS (shared, pooled) at the elastic entry point, ExaDB-D (dedicated, single-tenant) for the largest and most isolated and/or consolidated workloads, and the autonomous tiers (ADB-D and ADB-S) for serverless and fully managed operations.

Exascale vs Dedicated: how to choose

If you already run Exadata, or you are evaluating it, the question you actually face is a tier selection, and the answer is cleaner than most people expect.

A common misconception is that ExaDB-XS means your workloads share physical resources with other customers in a way that compromises isolation. That is not the case. Each customer operates independent VM Clusters and independent Storage Vaults. The separation between your vault and another customer’s vault is hard logical isolation – the same enforcement model that Oracle applies at the storage layer. In certain hardware configurations, there is an additional physical boundary as well, but the logical isolation alone is sufficient for most multi-tenant environments. The “shared” in ExaDB-XS refers to the fact that the underlying physical server pool is provisioned more densely than a dedicated rack, not to the fact that your data or your compute is ever visible to, or interleaved with, another tenant’s.

Given that isolation is not the differentiator, the decision is primarily economic:

Very large consolidation (dozens of ECPUs, multiple VM clusters running flat-out 24/7, high storage utilization): ExaDB-D is the right answer. The cost per ECPU converges and, at that scale, the dedicated tier’s lower unit price and full physical isolation make it the more economical choice.
Medium or small consolidation (a handful of ECPUs, elastic or intermittent demand, dev/test/non-production environments): ExaDB-XS is the sweet spot. You get the identical engine and feature behavior, the same isolation guarantees that matter for your compliance posture, and a dramatically lower entry point with the ability to scale down – even to the reserved-only state – when you are idle.

The storage management difference is the part DBAs will feel most immediately. On Exascale with 26ai, there is no ASM disk-group planning – storage auto-scales and redundancy is applied per object. On ExaDB-D, you still manage ASM disk groups and storage servers. If you are one of the people who has spent a week of your life planning disk-group geometry, you will understand precisely why this is a selling point rather than a footnote.

Oracle has emphasized that you can scale from small deployments to mission-critical environments without changing platforms, deployment models, or operational processes – and you can even run a cross-Region disaster recovery standby for an ExaDB-D environment on ExaDB-XS through cross-service Data Guard (Oracle Exascale blog). In practice that means your DR site can live on the cheaper, elastic tier while your production stays on dedicated hardware. That is a truly useful pattern.

Wrapping up

If you have been following along as a CIO or CTO rather than a database specialist, here is the plain-language version of everything above.

Oracle has spent the last few years doing something that sounded unlikely at the start: instead of competing with the big cloud providers, it has moved its flagship database engine inside their data centers, one by one. This week it finished that journey for the elastic tier of that platform. The result is that Oracle’s flagship commercial database – the one that runs financial trading, healthcare records, and global retail – is now available on AWS with the same pay-as-you-go, start-small economics you would expect from any modern cloud service.

Why it matters right now is simple: until this week, getting Exadata’s performance generally meant committing to a minimum amount of dedicated hardware, whether you needed it or not. That minimum is now gone. A team can start with a handful of compute units and a few hundred gigabytes, pay only for what it uses, and even stop paying for compute entirely when nothing is running – while keeping the exact same database engine and features as the largest deployments.

What changed is the reach, not the technology. The elastic Exadata tier now spans Oracle’s own cloud, Amazon, Microsoft Azure, and Google Cloud, all running the same software and the same pricing. For an organization that has already standardized on a cloud provider, that removes the last excuse for not considering Oracle’s engine: it now lives next door to the AI and analytics services you already use, with latency measured in microseconds.

The bottom line: Oracle has taken its most powerful database technology and made it ordinary – in the best sense. It is now something you can attach to a single project, grow incrementally, and run on whichever cloud your company already chose. For anyone who has watched Exadata from a distance for years, the distance just disappeared.