Exadata Exascale vs Traditional Exadata

On this page

1. 01 · Two Ways to Rent Exadata
2. 02 · What Traditional Dedicated Exadata Gives You
3. 03 · What Exascale Changes
4. 04 · Side by Side: Six Questions That Matter
5. 05 · Cost Model: When Each One Is Cheaper
6. 06 · Performance and Features
7. 07 · How to Choose Between Them
8. 08 · Moving Between Exascale and Dedicated
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Two Ways to Rent Exadata

Decision brief · Exascale (ExaDB-XS) versus dedicated Exadata (ExaDB-D)

"Do we really need a whole Exadata for this?"

For more than a decade, using Exadata meant committing to a physical system: an on-premises rack, an Exadata Cloud@Customer machine, or in the cloud a dedicated set of database and storage servers. That made perfect sense for a consolidated ERP or a large data warehouse. It made far less sense for a 300 GB departmental database, a fleet of developer copies or a new application whose size nobody can predict.

Exascale changes that. Exadata Database Service on Exascale Infrastructure (ExaDB-XS) went GA on OCI in July 2024, on Oracle Database@Azure in March 2025 and on Oracle AI Database@AWS on 13 August 2026, and is available on Oracle AI Database@Google Cloud. It pools Exadata database and storage servers across many tenants and gives each one a VM cluster that draws from those pools. Traditional Exadata Database Service on Dedicated Infrastructure (ExaDB-D) is still there, and still the right answer for many estates. The question is which shape fits which workload.

02 · What Traditional Dedicated Exadata Gives You

Answer: ExaDB-D gives one customer a dedicated Exadata infrastructure: at least two database servers and three storage servers, on which you create one or more VM clusters. You pay for the infrastructure plus the ECPUs you enable, control maintenance windows, and can grow by adding servers.

With dedicated infrastructure, the unit of purchase is hardware. You provision an Exadata infrastructure resource, choose the number of database and storage servers, and then carve VM clusters out of it. Every VM cluster you create shares only your own servers. You decide when Oracle applies infrastructure maintenance, within the windows the service allows, and you can run several VM clusters with different Grid Infrastructure and database versions side by side.

This is the model behind most large Exadata cloud estates today. It is predictable, it isolates noisy neighbours at the physical level, and it supports the widest range of database releases and Exadata features, including Autonomous AI Database on Dedicated Exadata Infrastructure. The trade-off is the entry cost: even an idle system pays for its servers.

03 · What Exascale Changes

Answer: Exascale removes the dedicated-hardware unit. Oracle runs large shared pools of Exadata database servers and storage servers; each customer gets VM clusters and Exascale storage vaults that draw from those pools. You pay only for the ECPUs and storage you use, and data access still uses Smart Scan, storage indexes and RDMA.

Under Exascale, the Exadata storage servers become a multi-tenant storage cloud and the database servers become a pool of compute that hosts VMs from many customers. Your databases live in an Exascale storage vault, a logical container with its own capacity and security boundary. Because storage is pooled and metadata-driven, Exascale can create space-efficient thin clones and snapshots of whole databases without copying every block.

The topology below contrasts the two models inside the same Oracle-operated Exadata site. On the left, one customer owns the servers and its VM clusters sit on them. On the right, several tenants' VM clusters share a compute pool and keep their data in separate vaults inside a shared storage pool. In both cases the OCI parent region provides the control plane.

The key difference is what sits under your VM cluster. On the left, the black RDMA arrows run only to your own storage servers. On the right, the same RDMA data path runs into a shared pool, and the vault is what separates your data from the next tenant's.

04 · Side by Side: Six Questions That Matter

Answer: ExaDB-D rents servers, bills infrastructure plus ECPUs, scales within and then beyond your hardware, isolates physically and has a quarter-rack class minimum. ExaDB-XS rents a VM cluster, bills ECPUs plus storage, scales compute and storage independently, isolates logically and starts very small.

Most comparisons drown in feature lists. In practice six questions decide the choice: what you rent, how you are billed, how you scale, how you are isolated, how you clone, and how small you can start. The panel answers each for both models, with the shared Exadata software in the centre column as the common ground.

Read across each row rather than down each column. Billing and minimum size favour Exascale for anything small or variable. Isolation and maintenance control favour dedicated infrastructure. Cloning is where Exascale is strongest for development and test teams.

Operational differences DBAs notice

05 · Cost Model: When Each One Is Cheaper

Answer: Exascale is cheaper whenever the workload does not fill a dedicated system, because you pay nothing for idle servers. Oracle quotes up to 95% lower minimum infrastructure cost than ExaDB-D. Dedicated infrastructure becomes competitive when a large, steady estate keeps the servers busy and you can use the capacity you already pay for.

The two models put cost in different places. ExaDB-D has a fixed component, the hourly charge for each server, plus a variable component, the ECPUs you enable. Exascale has no fixed infrastructure component: you pay for ECPUs and for storage capacity in gigabytes, and there is no separate charge for IOPS. That is the source of Oracle's claim of up to 95 percent lower minimum infrastructure cost.

The break-even depends on utilisation, not on database size alone. A dozen medium databases that together keep two database servers busy around the clock may cost less on ExaDB-D than as a dozen Exascale clusters. A single large but bursty warehouse might be cheaper on Exascale because it can scale ECPUs up for the nightly load and back down afterwards.

06 · Performance and Features

Answer: Exascale keeps the core Exadata performance features: Smart Scan offload, storage indexes, Exadata RDMA memory and RDMA-based data access. Per-database performance is comparable for most OLTP and analytics workloads. Differences are in isolation guarantees, supported releases and features tied to dedicated infrastructure.

Because both services run the Exadata system software, SQL that benefits from Smart Scan on dedicated infrastructure benefits on Exascale too. The database still pushes predicates and column projection to the storage servers, uses storage indexes to skip regions, and reads hot data over RDMA. What changes is that the storage servers are shared, so Oracle's resource management between tenants, rather than physical separation, keeps one tenant from affecting another.

The practical checks before choosing Exascale for a production workload are short. Confirm that your database release is supported on Exascale on your platform. Confirm that any features you depend on, such as specific Autonomous options or particular network or security integrations, are listed for ExaDB-XS in your region. And load-test with your real workload, especially if it is latency-sensitive, before you commit.

07 · How to Choose Between Them

Answer: Choose ExaDB-D when you need physical isolation, have a large steady estate that fills servers, or depend on releases or features Exascale does not yet offer in your region. Choose ExaDB-XS for small to medium databases, development and test fleets, variable workloads and new applications.

The decision flow below asks four questions in order. Each question that is answered yes sends you to dedicated infrastructure, for a specific reason. If none applies, Exascale is the default. On the right are the workload patterns that most often land on each side, which helps when you are sorting a whole portfolio rather than one database.

The order matters. Isolation and compliance come first because they are not negotiable. Region availability comes last because it is temporary: a workload that lands on ExaDB-D only because Exascale is missing in its region is a candidate to move later.

1. Inventory the portfolio. List each database with size, peak and average ECPU, release, isolation needs and region.
2. Apply the four questions. Mark each database for ExaDB-D or ExaDB-XS and note the deciding reason.
3. Group the ExaDB-D candidates. If they fill at least a minimum dedicated system, price one shared infrastructure for them.
4. Price both totals. Compare a mixed estate (some dedicated, some Exascale) with all-in options.
5. Pilot. Move one representative workload to Exascale and measure before converting the rest.

08 · Moving Between Exascale and Dedicated

The choice is not permanent. Both services run the same database software, so moving a database between them uses standard Oracle tools:

1. Data Guard. Create a standby on the target service and switch over. This is the lowest-downtime path and is what Zero Downtime Migration (ZDM) automates for physical online migration.
2. RMAN. Restore from backup or use RMAN duplicate for databases that can accept a short outage.
3. Data Pump and GoldenGate. Use logical migration when you also want to upgrade the release, reorganise schemas or consolidate into a pluggable database.
4. Thin clones for testing. Before moving, clone the Exascale copy repeatedly to rehearse cutover and application tests without paying for full copies.

A common pattern is to start a new application on Exascale, let it grow, and move it to dedicated infrastructure only if and when its steady load would fill servers on its own. The reverse also happens: databases consolidated on ExaDB-D years ago are moved to Exascale when the dedicated system comes up for renewal.

Dedicated Exadata is something you size. Exascale is something you consume. Most estates end up with some of each.

09 · Key Takeaways

1. Same software, different unit of purchase. ExaDB-D rents whole servers; ExaDB-XS rents a VM cluster on shared Exadata pools.
2. Exascale wins on entry cost. ECPU and GB billing with no IOPS or server charge; Oracle quotes up to 95% lower minimum infrastructure cost.
3. Dedicated wins on isolation and control. Physical isolation, customer-scheduled maintenance and the broadest release and feature support.
4. Thin clones change dev and test. Exascale snapshots and clones make frequent refreshes cheap and fast.
5. Decide per workload, not per estate. Isolation, steady scale, release support and regional availability route each database; most estates use both.

10 · Frequently Asked Questions