Oracle Exadata vs Exadata Cloud@Customer: What's Actually Different?

At first glance, Oracle Exadata and Oracle Exadata Cloud@Customer look almost identical. Both use Oracle Exadata hardware. Both run Oracle Database. Both support RAC, ASM, Smart Scan, Storage Cells, and Flash Cache.

So why does Oracle offer two different deployment models? The answer is not about database performance — it is about who owns the infrastructure, who manages it, and how your organization wants to operate its mission-critical databases.

One gives you complete ownership and control over every component. The other delivers the same Exadata platform with Oracle Cloud automation while keeping your databases inside your own data center.

Whether you deploy a traditional on-premises Exadata machine or an Exadata Cloud@Customer (ExaCC) rack, you get the same high-performance engineered system designed specifically for Oracle Database workloads.

Both models share the foundational Exadata building blocks:

• Compute Nodes — high-performance database nodes running Oracle Linux
• Storage Cells — intelligent storage servers running dedicated Exadata Storage Server software
• Smart Scan — offloading mechanism pushing query predicate filtering and column projection down to the storage layer
• Flash Cache — ultra-fast NVMe flash layers accelerating random data block access
• ASM & RAC — Automatic Storage Management and Real Application Clusters for active-active HA
• RoCE Networking — sub-millisecond RDMA over Converged Ethernet latencies connecting compute and storage layers

What remains identical is raw execution performance. A heavy analytics query or a high-throughput OLTP workload runs with the same efficiency and execution plans across both platforms, assuming identical hardware generations.

The core divergence lies within the management layer and provisioning boundary. Traditional Exadata places the operating system directly on bare metal or within manually built OVM/KVM hypervisors. ExaCC pre-virtualizes the hardware using an optimized, Oracle-managed KVM hypervisor that hooks into the remote Oracle Cloud Infrastructure (OCI) control plane.

Table 1 · Core architectural element comparison matrix

Ownership is where the operational realities split. With a traditional Exadata deployment, the physical rack, compute blocks, power distribution units (PDUs), RoCE switches, and storage servers live on your balance sheet as Capital Expenditure (CapEx). This means your internal infrastructure team owns the risk — handling everything from initial data center floor preparation to physical lifecycles and deprecation.

Your teams must handle facilities inspection, power drop provisioning, network cabling, and physical racking. You negotiate ongoing hardware maintenance renewals and actively plan for physical obsolescence, executing a comprehensive lift-and-shift migration every four to five years to refresh underlying assets.

With Exadata Cloud@Customer, Oracle retains full legal ownership of the physical hardware. Oracle ships the asset to your data center floor, but it remains a remote node of Oracle Cloud Infrastructure. You do not purchase the system — you subscribe to it with an ongoing subscription agreement. Oracle tracks the asset lifecycle, performs initial physical installation, and manages hardware replacements.

Because Oracle owns the physical box, they are contractually obligated to guarantee availability up to the hypervisor layer. Your infrastructure specialists stop coordinating with hardware vendors for component failures and focus exclusively on data consumption and database design.

Figure 1 · Oracle Exadata vs Exadata Cloud@Customer architecture comparison

In a standard on-premises Exadata environment, your corporate technology team is entirely responsible for the full stack. If an NVMe flash card or power supply module degrades on a storage cell, your team triages the alert via Oracle Enterprise Manager (OEM), opens a Service Request (SR), receives replacement parts, and orchestrates the physical replacement. System administrators manually monitor, patch, and maintain RoCE switch configurations, storage cell firmware, and Xen/KVM hypervisor software layers.

Exadata Cloud@Customer restructures this dynamic with a clear dividing line between infrastructure maintenance and database management. Oracle Cloud Operations handles all infrastructure management up to the hypervisor layer — continuously monitoring hardware components, network infrastructure, storage server software, and hypervisors. If a component fails, Oracle proactively dispatches resources to swap parts without requiring manual triage from your DBAs.

Your team retains absolute control over the Virtual Machine (VM) Clusters running inside the hypervisor, the Oracle Database software directories ($ORACLE_HOME), and the databases themselves. You retain complete SYSDBA access, enabling you to configure database parameters, manage tablespaces, and enforce custom security profiles, while offloading the monotonous hardware plumbing to Oracle.

Figure 2 · Infrastructure stack responsibility breakdown

On a standard on-premises Exadata machine, patching is a highly complex orchestration project. Internal DBA and system administration teams manually download quarterly Release Updates (RUs) along with specialized Exadata infrastructure bundles. They review compatibility matrices, evaluate interdependency conflicts between firmware and database versions, run pre-validation check scripts, and execute rolling updates across storage servers and compute nodes.

Because an unvalidated firmware clash can take down a mission-critical RAC cluster, on-premises patching frequently induces operational analysis paralysis. Teams often fall multiple quarters behind on critical Security Release Updates (RUs) simply because the manual orchestration and pre-testing overhead is so demanding.

Exadata Cloud@Customer decouples the layers. For the infrastructure layer — storage cell software, RoCE network switches, and hypervisors — Oracle Cloud Operations takes charge. Oracle notifies you of required infrastructure maintenance windows. Once scheduled via the OCI console, Oracle Cloud automation handles the rolling update of underlying infrastructure components without disrupting running guest VMs.

For the guest operating system, Grid Infrastructure, and individual Oracle Database software homes, patching is executed by your internal team but accelerated via OCI APIs and automation tools. Rather than executing manual command-line patch actions across dozens of nodes, a DBA can log into the OCI Console, select the target Database Home, and initiate a pre-check or rolling patch with a button click or an automated API payload via OCI CLI or Terraform.

Capacity planning under a traditional on-premises Exadata model requires rigorous foresight. If your data warehouse grows faster than anticipated, expanding a traditional rack requires physical capital procurement — mapping hardware needs, securing executive capital approval, issuing purchase orders, waiting weeks for manufacturing and shipping, and arranging for an Oracle field engineer to physically scale the rack.

This physical procurement cycle naturally forces infrastructure teams to over-provision. Enterprises routinely buy 30% to 50% more headroom than their baseline requires just to avoid being caught short during peak quarters, leaving expensive, depreciating compute assets sitting cold on the floor.

Exadata Cloud@Customer approaches scalability through an elastic cloud lens, despite residing locally inside your corporate facility. Your organization activates and pays for the specific number of CPU cores required to handle the immediate workload profile. Through the OCI control plane, DBAs dynamically scale OCPUs up or down within VM clusters on demand, with zero downtime.

If an online retailer hits a massive peak during Black Friday trading, they scale up compute resources instantly via script or console UI. Once the traffic spike subsides, they scale down to baseline usage. This variable consumption framework breaks the link between physical hardware constraints and active database resource provisioning.

Figure 3 · Physical procurement vs elastic OCPU scaling

Traditional Exadata is built on CapEx. Upfront, the enterprise makes a large capital investment to acquire physical hardware assets, alongside procurement costs for long-term perpetual database and option licenses. Over time, costs are amortized over a fixed financial lifecycle, augmented by recurring annual software update and hardware support contracts.

This CapEx model is highly predictable for long-term enterprise budgeting but lacks commercial agility. If a business unit spins down a major application, the physical hardware asset cannot be returned to reclaim capital — it remains an unalterable sunk cost.

Exadata Cloud@Customer is structured completely as OpEx. There are no upfront hardware procurement costs. Instead, you pay an ongoing monthly infrastructure subscription fee for the physical platform running in your data center, paired with consumption billing for OCPUs utilized within the system.

ExaCC natively incorporates Oracle's Bring Your Own License (BYOL) framework as well as the License Included billing option. License Included bundles the cost of Oracle Enterprise Edition Database along with enterprise options — RAC, Advanced Security, Multitenant, and Partitioning — into a consolidated hourly consumption metric, shifting database software licensing from fixed liabilities into elastic operational costs.

Example 1: Large Financial Institution

Requirements: Absolute control over data sovereignty, isolation from public networks, an internal database infrastructure team, and a long-term capital depreciation roadmap.

Recommended: Oracle Exadata (On-Premises). Large financial institutions often possess established infrastructure units that excel at hardware lifecycle optimization. Because internal security mandates may strictly forbid continuous outbound telemetry connections to an external cloud control plane, a traditional bare-metal on-premises Exadata machine provides complete air-gapped isolation and asset-level governance.

Example 2: Healthcare Enterprise

Requirements: Strict patient data residency compliance, automated database management workflows to alleviate stretched IT staff, and agile modern app integration.

Recommended: Exadata Cloud@Customer (ExaCC). The healthcare enterprise must legally keep electronic health records (EHR) on physical infrastructure inside national or corporate boundaries. However, they lack the massive dedicated infrastructure staff needed to manage complex storage firmware updates and hardware tracking. ExaCC allows them to maintain strict local data residency while benefiting from Oracle-managed infrastructure and simplified automated patching.

Example 3: Government Organization

Requirements: Localized deployment within secure regional data facilities, highly restrictive fiscal operating budgets with limited access to senior system engineers.

Recommended: Exadata Cloud@Customer (ExaCC). Government agencies frequently face severe hiring restrictions, making it extremely difficult to attract and retain senior infrastructure engineers skilled in optimizing complex engineered systems. ExaCC offloads hardware administration, switch firmware configuration, and storage cell management to Oracle Cloud Operations.

Example 4: Enterprise Modernizing to OCI

Requirements: Hybrid cloud integration, deployment of modern cloud APIs, unified application tooling, and gradual migration of monolithic on-premises Oracle workloads.

Recommended: Exadata Cloud@Customer (ExaCC). For companies executing a multi-year migration plan toward a pure cloud architecture, ExaCC serves as the definitive stepping stone. It introduces the identical OCI management APIs, Terraform automation standards, and cloud console user interfaces utilized in the public cloud — allowing engineering teams to standardize automation scripts locally before executing a final migration into a public OCI Exadata Database Service region.

Figure 4 · Enterprise decision tree matrix

1. ExaCC is simply hosted ExadataReality: Hosted Exadata implies standard on-premises hardware placed into a third-party co-location facility. ExaCC is fundamentally distinct — the physical rack sits inside your data center but is deeply integrated into the OCI cloud fabric via software APIs, bringing automated cloud provisioning, billing structures, and managed infrastructure operations through your data center firewall.
2. Oracle owns and can access customer databases in ExaCCReality: Oracle retains ownership of physical hardware and the hypervisor tier. Oracle does not have access to your database instances, encryption keys, or data layers. You retain absolute control over guest VM operating system logins and administrative database accounts.
3. Traditional Exadata is faster than ExaCCReality: Raw database execution performance across identical hardware generations is equivalent. Both models take full advantage of Smart Scan block offloading, high-speed NVMe flash caching, and ultra-low latency RoCE networking. ExaCC can occasionally exhibit faster operational turnarounds for provisioning or cloning due to built-in OCI control plane orchestration.
4. ExaCC completely eliminates the need for DBA staffReality: While ExaCC offloads hardware maintenance, OS hypervisor deployment, and routine firmware patching to Oracle, it does not replace the strategic role of a DBA. Your database administrators remain fully responsible for schema design, index optimization, SQL performance tuning, database security auditing, data modeling, and business continuity architecture.

Assess Network Readiness for ExaCC

Ensure your data center network layout can accommodate the required secure OCI telemetry connection. Validate proxy servers, internal routing tables, and firewall configurations against Exadata Cloud@Customer requirements to guarantee seamless API communications without violating corporate data compliance boundaries.

Align the Financial Strategy

Coordinate early with corporate finance officers. If your organization operates under strict corporate capitalization frameworks where hardware assets are preferred for tax depreciation, traditional on-premises Exadata matches that financial profile perfectly. If your goal is to transition tech liabilities into flexible operating expenses, target the OpEx framework of ExaCC.

Prepare the Operational Team

Shift your internal DBA team's mindset from purely tactical maintenance engineers to strategic data architects. Under ExaCC, training should emphasize OCI API orchestration, Terraform automated infrastructure deployments, and cloud lifecycle integration. For deeper OCI automation skills, see our guide on Mastering the OCI Command Line Interface for DBAs.

Adopt Modern Backup Topologies

Leverage optimized network links on either system to build robust backup targets. For ExaCC, utilize integrated backup pathways leading directly to OCI Object Storage for cost-effective offsite retention, or deploy a local Zero Data Loss Recovery Appliance (ZDLRA) to achieve real-time transaction protection.

• Do we want to eliminate physical hardware asset management and lifecycle replacement cycles?
• Does our internal team possess the bandwidth to execute manual firmware and network switch updates quarterly?
• Do corporate accounting preferences lean toward upfront Capital Expenditures (CapEx) or predictable monthly Operational Expenditures (OpEx)?
• Do our external compliance constraints require physical systems to remain strictly within corporate walls while utilizing cloud tooling?
• Do we want to enable database self-service provisioning and dynamic OCPU scaling for application developers?
• Is our organization planning a broader, multi-year migration path toward the public Oracle Cloud Infrastructure (OCI) ecosystem?

1. Same core technologyOracle Exadata and ExaCC use the same core Exadata technology, delivering the same database capabilities and performance architecture.
2. Ownership is the biggest forkTraditional Exadata is customer-owned; ExaCC is delivered as an Oracle-managed cloud service inside your data center.
3. Operational responsibility shiftsOn-premises Exadata requires customers to manage hardware lifecycle, firmware, and infrastructure operations; Oracle manages these layers in ExaCC.
4. Cloud integration without data egressExaCC integrates with OCI services, APIs, and cloud automation while allowing sensitive databases to remain on-premises.
5. Patching model differsInfrastructure patching is primarily customer-managed in Exadata but Oracle-managed in ExaCC, reducing operational overhead.
6. CapEx vs OpExExadata typically follows CapEx; ExaCC uses a subscription-based OpEx approach with elastic OCPU billing.
7. Enterprise features intactBoth platforms support RAC, ASM, Smart Scan, Flash Cache, Storage Cells, and high availability.
8. Choose on operations, not performanceThe right choice depends on ownership model, operational responsibility, and cloud strategy — not raw SQL performance.

Oracle Exadata and Exadata Cloud@Customer are not competing products — they are different ways of consuming the same engineered system. The right choice depends less on technology and more on how your organization wants to own, operate, and evolve its Oracle database platform.

Choosing between them is not about performance — it is about selecting the ownership model, operational responsibility, and cloud strategy that best fits your organization.

At ExaGuru, our Exadata Expert course covers both on-premises Exadata and ExaCC deployment models — because understanding the operational boundary is the foundation for every migration and architecture decision that follows.