Exadata X11MV: 50% More VM Density and What It Means for Your Cloud Exadata Consolidation Strategy

I’ve been tracking the Exadata Cloud Infrastructure release notes for a while now, and the June 30 entry caught my attention in a way that went beyond the usual quarterly feature list. Oracle has quietly released a new infrastructure generation for Exadata Database Service on Dedicated Infrastructure that changes the consolidation math for a lot of customers in a very practical way. The hardware is the same as the X11M you already know. What’s different is the ceiling on how much you can pack onto it.

The new generation is called X11MV. It supports up to 12 virtual machines per database server, up to 24 VM Clusters per system, and up to 1.7 TB of /u02 filesystem space per VM. If you’re running on X11M today, that’s a 50% increase in VMs per server, a 3x increase in the number of isolated VM Clusters, and nearly 2x the local storage capacity for database homes. The ECPU billing metrics are the same as for X11M. That matters, but it needs to be considered together with the separate charge for the underlying dedicated infrastructure.

Before we get into the limits, one clarification that saves a lot of confusion. In this article, X11MV refers to the infrastructure model for Exadata Database Service on Dedicated Infrastructure (ExaDB-D). It is not the same thing as Exadata Database Service on Exascale Infrastructure (ExaDB-XS, the shared, Oracle-managed, Exascale-based service), and it is not Oracle Database@Customer (Cloud@Customer, the on-premises deployment in your own site). X11MV is also available for Autonomous AI Database on Dedicated Exadata Infrastructure in OCI public cloud and multicloud, which is relevant when the two services coexist on the same infrastructure.

What X11MV Is (and What It Isn’t)

The first thing worth getting straight is that X11MV is not a new hardware platform. The database servers are the same 5th Generation AMD EPYC machines. The storage servers are the same X11MV-HC high-capacity units with 1.25 TB of XRMEM and 27.2 TB of NVMe flash. The DDR5 memory, the RoCE fabric, the Exadata Storage Server Software stack with Smart Scan and AI Smart Scan, the XRMEM data accelerator with SQL read latency as low as 14 microseconds, all of that is identical to X11M.

What Oracle has done is introduce higher limits for VM density, VM Cluster count, and /u02 storage per VM while running on the same underlying hardware platform as X11M. The increase is achieved through the X11MV software configuration rather than new physical components. The physical capacity was there all along. X11MV gives you access to more of it.

A second clarification is about storage, because this is where the ExaDB-D versus ExaDB-XS distinction becomes concrete. ExaDB-D has traditionally used ASM on the Exadata storage servers, and an ASM VM Cluster remains a fully supported choice on X11MV. But X11MV does not require ASM: when a VM Cluster is created, the database storage type can be selected as ASM or Exascale. That choice is permanent for that VM Cluster, and the Exascale option has specific software and database-version prerequisites.

This is a meaningful distinction for planning purposes. If you’re on X11M in a region where X11MV is available, plan this as a new X11MV infrastructure resource and a migration of the required databases and VM Clusters. Data Guard, RMAN, and Zero Downtime Migration can be appropriate database-migration mechanisms depending on the workload and migration design. This is not an in-place conversion of an existing X11M infrastructure resource. No re-platforming, no change to the database software stack.

The two new SKU identifiers are X11MV for database servers and X11MV-HC for high-capacity storage servers. The minimum elastic configuration is 2 database servers and 3 storage servers, expandable up to 32 database and 64 storage servers, same as X11M.

What the Raised Limits Actually Change

Oracle’s Exadata Product Management team has been very clear about the thinking behind X11MV. Kevin Deihl, Director of Product Management, published a post on the Oracle Database Insider blog in early July that frames the strategy as maximizing consolidation density at every layer of the stack. Three limits moved at once, and they all point the same direction: more room to consolidate.

More VMs per Server

The jump from 8 to 12 VMs per database server is the most straightforward improvement. If you’re running one VM per database, as many organizations still do for isolation reasons, a fully populated X11MV server now hosts 12 isolated database environments instead of 8. On a maximum-size system with 32 database servers, that’s 384 VMs versus 256 on X11M.

This matters in practice because one of the common patterns in Exadata estates is “one VM, one database, one application.” It’s clean, it’s easy to reason about, and it provides full OS-level isolation. But it means you’re paying for a lot of unused capacity on each VM. The 50% density increase directly reduces the infrastructure cost per database for that pattern, without any change to how you organize your workloads.

A Higher Ceiling on VM Clusters (Not a Reason to Use More)

The increase from 8 to 24 VM Clusters per system is the change that has the most strategic implications, but I want to be careful about how we frame it, because the obvious reading is a trap.

A VM Cluster is the unit of isolation in Exadata Cloud Infrastructure. Each VM Cluster has its own Grid Infrastructure, its own network configuration, its own access controls, and its own compute, memory, and storage allocation. On the surface, “24 instead of 8” looks like an invitation to build more isolated environments. In my experience advising customers, that is usually the wrong instinct.

The default posture I recommend has not changed, and X11MV does not change it either: create the minimum number of VM Clusters you genuinely need, and work with large shared pools of resources. Every VM Cluster you create compartmentalizes CPU, memory, and storage. The more clusters you run, the more your resources get split into smaller silos, and the harder it becomes to size each one well and to reuse the idle capacity sitting in one cluster to absorb a spike in another. Fewer, larger clusters give you big pools that are easier to right-size, easier to balance, and easier to consolidate into over time. That philosophy, on ExaDB-D, is the same before and after X11MV.

So why did Oracle raise the ceiling? Because the old ceiling of 8 was a hard wall that forced compromises on real workloads. The raised limit doesn’t change the default philosophy; it removes a constraint that previously made certain legitimate exceptions impossible to solve. Concretely, the 24-cluster ceiling now makes it practical on a single system for cases like:

A “multi-jurisdiction” estate where a regulatory data-residency requirement genuinely forces a separate VM Cluster per jurisdiction. For a European financial services company with branches in France, Germany, and Spain, keeping each jurisdiction’s data inside its own border is a hard isolation requirement, not a preference. On X11M you might have had to split that across two Exadata systems; on X11MV the whole set fits on one, while you still keep the clusters as few as the regulation actually demands.
A workload pattern that legitimately needs many small, tightly isolated VM Clusters, where sharing a larger pool would violate a security, tenancy, or blast-radius requirement that cannot be met any other way.

In both cases the point is the same: you are still designing for the minimum number of clusters that satisfies a hard requirement. The raised ceiling just means that when a hard requirement does exist, you no longer hit a wall that pushes you toward a second Exadata system or toward a compromise in isolation. If you have no such hard requirement, the answer is still a small number of large, well-sized clusters.

More Room in the Local /u02 Filesystem per VM

The /u02 filesystem is where Oracle Database homes live on the compute side. On X11M, each VM could claim up to 900 GB of /u02. On X11MV, that limit is 1.7 TB (1740 GB). This is, again, less a call to use more storage and more the removal of a ceiling that created a real operational pain point.

One of the more common support requests in Exadata estates is “we ran out of space on /u02.” It happens when a customer maintains multiple Oracle home versions side by side (say, a 19c home and a 26ai home for a rolling upgrade), or when a database home needs space for out-of-place patching workspaces, multiple Grid Infrastructure versions, or extended diagnostic logging. Previously, the 900 GB ceiling meant some of these scenarios simply did not fit in one VM, and you had to either split them or keep cleaning homes under pressure.

The raised 1.7 TB per-VM limit is exactly the kind of “exception that couldn’t be solved before.” It lets a VM that legitimately needs a large filesystem have one, for example when maintaining 19c and 26ai database homes side by side for a rolling upgrade. There is an important capacity caveat: a database server provides 2,243 GB of usable local storage, while the minimum/default VM image is 244 GB. Twelve default local VM images would require 2,928 GB, so the maximum density of 12 VMs per server cannot be planned using only database-server local VM storage at default sizes. Designs that need that density, or large VM filesystems, must account for aggregate capacity and may use Exascale VM filesystem storage where applicable.

Consolidation Strategy: How I’d Actually Think About X11MV

The density increase doesn’t automatically make your consolidation strategy better. It gives you more room to build a strategy that was previously constrained. Here’s how I’d think about applying X11MV to a consolidation plan.

Start From the Default: Few Clusters, Big Pools

The first decision is not “how many VM Clusters can I use” (the answer is now up to 24). The first decision is “how few can I get away with while still meeting every hard isolation requirement I actually have?” Work from a baseline of large, shared VM Clusters. Within each cluster, use Multitenant for intra-VM consolidation: Oracle’s official Multitenant best practices recommend Container Databases with Pluggable Databases, and a single CDB can host up to 4,096 PDBs that can be unplugged, moved, or re-plugged with minimal disruption.

The combination of VM-level isolation (few, large VM Clusters) and PDB-level consolidation (Multitenant) gives you a two-tier model where the big pools stay big. The VM Cluster is the hard isolation boundary; the PDB is the soft consolidation boundary within it. The result is fewer silos, larger pools of CPU, memory, and storage, and a much easier time right-sizing and reusing idle capacity.

Then, and Only Then, Split a Cluster for a Hard Requirement

Once the large-cluster baseline is set, look for the specific cases where sharing would be wrong, and split a VM Cluster only for those. Typical triggers are a regulatory data-residency boundary, a strict security or blast-radius requirement, or a tenancy separation that cannot be expressed inside one shared pool. This is where the raised 24-cluster ceiling earns its keep: those splits now fit on a single system instead of pushing you to a second Exadata box. A European financial services or manufacturing estate with per-jurisdiction data residency is the textbook example, and one reason to keep an eye on the Exadata release notes for X11MV regional availability: At launch, X11MV for ExaDB-D was available in eight listed regions: San Jose, VKZ1, Paris, Cardiff, Vinhedo, Osaka, Melbourne, and Hyderabad, with rollout to other regions in phases.

Use the Raised Limits to Buy Headroom, Not to Compartmentalize

The two raised ceilings that are about headroom rather than isolation are the per-VM /u02 limit and the per-server VM count. Use the 1.7 TB /u02 limit to give a VM that genuinely needs a large local filesystem (multi-home rolling upgrades, out-of-place GI patching, large local scratch) the room it needs, instead of splitting a workload across VMs just to dodge the 900 GB ceiling. Use the higher per-server VM count to add isolation where it’s cheap, not to reach for the maximum.

The Economics: Unchanged Pricing

The ECPU billing rate for X11MV is the same as X11M: $0.336 per ECPU per hour for License-Included subscriptions, and $0.0807 per ECPU per hour for Bring Your Own License (BYOL).

This is where the consolidation math gets interesting. Adding more VMs to the same physical servers doesn’t change your bill unless you’re actually consuming more ECPUs. But the density increase means you can consolidate more workloads onto the same servers without scaling up the hardware. The infrastructure cost is spread across more databases.

For BYOL, licensing is based on enabled ECPUs, not on the count of physical database servers. Consolidation can reduce the infrastructure footprint, but it changes BYOL license requirements only if it also changes the enabled ECPU requirement under the applicable conversion rules. For License-Included customers, it reduces the total ECPU hours you’re billed for because you can consolidate and turn off unused ECPUs.

The 48-hour minimum applies to the infrastructure resource; afterward it is billed by the second. ECPUs are billed by the second with a one-minute minimum. The minimum ECPU allocation per VM is 8 ECPUs for ExaDB-D. You can scale ECPUs up or down online without downtime, which means you can right-size each VM’s compute allocation as workload patterns change.

Autonomous Database on the Same Infrastructure

One aspect of X11MV that gets less attention than it deserves is the ability to run Autonomous AI Database on the same Exadata infrastructure as Exadata Database Service, each in its own VM Cluster.

The X11MV support for Autonomous AI Database on Dedicated Infrastructure was announced slightly earlier, on June 24, 2026. The limits are different: Autonomous AI Database supports up to 6 VMs per database server (not 12), and uses ECPU-only billing. But the key point is that both services can coexist on the same physical Exadata system, in separate VM Clusters, with independent access controls and networking. This is a clean application of the “one cluster per hard requirement” rule: the autonomous workload gets its own cluster, and everything else stays in the large shared pools.

This is a practical consolidation pattern for organizations that are transitioning from self-managed to autonomous databases at a gradual pace. You can run your existing ExaDB-D databases in one set of VM Clusters and your new Autonomous AI Database workloads in another, all on the same infrastructure. Over time, as workloads migrate from ExaDB-D to Autonomous, the cluster count naturally decreases, and you can eventually consolidate to a smaller infrastructure.

For organizations with AI workloads, the combination of Exadata’s AI Smart Scan (which accelerates vector search at memory speed via XRMEM) and the density of X11MV means you can run AI applications that access mission-critical transactional, analytical, and vector data in real time, all on the same platform. This eliminates the data movement complexity and cost that comes with running AI workloads on a separate infrastructure.

What I’d Actually Do With X11MV

If I were planning a consolidation strategy for a European financial services or manufacturing customer right now, here’s the shape it would take.

Step 1: Inventory the current estate. Count the databases, the VMs, the VM Clusters, and the infrastructure servers. Identify the VM Clusters that exist today and the hard isolation requirements that actually exist (jurisdiction, security domain, lifecycle).

Step 2: Design from the default of large clusters. Build a baseline of the fewest VM Clusters that covers every hard requirement, with big shared pools of CPU, memory, and storage. Use Multitenant (PDBs) for intra-VM consolidation so the pools stay large. Don’t design for 24. Design for the minimum that satisfies a real requirement, plus a reasonable buffer for growth.

Step 3: Split a cluster only where a hard requirement demands it. This is where the raised 24-cluster ceiling helps: multi-jurisdiction data residency, strict tenancy, or a tight blast-radius requirement that can’t be met inside one shared pool now fits on a single system instead of pushing you to a second Exadata box.

Step 4: Use the raised limits for headroom, not to compartmentalize. Give the VM that genuinely needs a large local /u02 (multi-home rolling upgrade, out-of-place GI patching, large scratch) the 1.7 TB it needs. Add VM-level isolation where it’s cheap.

Step 5: Build the IORM and NRM policies before you consolidate in. In a big-pool strategy, the fairness layer is what keeps one workload from degrading the rest. This is the step most organizations skip, and the one that decides whether consolidation works in production.

Step 6: Migrate in phases. Start with the least critical workloads. Use Oracle Data Guard to set up the target environment, validate, then cut over. The larger /u02 and higher VM density mean you can migrate more workloads per phase than on X11M.

Step 7: Monitor and adjust. After the first 30-60 days, review IORM metrics, network utilization, and storage consumption. Right-size the large pools based on actual workload behavior, not the initial design assumptions, and reuse idle capacity across the pool rather than spinning up new clusters.

Wrapping up

Oracle has released a new generation of its cloud Exadata infrastructure called X11MV, currently aimed at one specific service: the dedicated-infrastructure Exadata in OCI and multicloud (ExaDB-D). The physical hardware is the same as the current X11M, and the database storage is still managed the same way, through ASM on the Exadata storage servers. So this is not a move to a different architecture. What Oracle has raised are the ceilings on how much you can consolidate on a single system.

The practical effect is that the limits that used to force compromises are now higher. You can fit roughly half again as many isolated databases on each server, and the cap on the number of separate, isolated database environments per system has been tripled. Local storage per database environment has also nearly doubled.

Finally, more headroom is not an invitation to fragment your estate into many small, isolated boxes. The sound approach, unchanged by this release, is to run as few large environments as you genuinely need and to keep your pools of compute, memory, and storage big, so they are easy to right-size and easy to share. The new limits matter when a real, non-negotiable requirement comes up, such as keeping different jurisdictions’ data on the same physical system while each one stays inside its own border, or giving one workload the large local storage it genuinely needs. Those are the cases the old ceiling made impossible, and they are exactly the exceptions X11MV now makes practical on a single system.