ExaCS vs ExaCC Compared

Exadata in the cloud comes in two forms, and the choice between them is one of the more consequential decisions in any Oracle estate. Exadata Cloud Service, or ExaCS, places the engineered system inside an Oracle data centre and delivers it to you as a public cloud service. Exadata Cloud at Customer, or ExaCC, places the same engineered system inside your own data centre while Oracle manages it remotely. They share the hardware and the database capabilities, so the performance story is largely identical, but everything around them differs: where the data sits, who controls the facility, how it is billed, and which compliance and latency constraints it satisfies. This article compares the two so you can choose on the merits rather than on a default.

For the broader context of what Exadata offers, start with our complete guide to Exadata Cloud Service. Here we focus narrowly on the ExaCS versus ExaCC decision.

The core difference is location and control

The single distinction from which everything else follows is where the machine physically lives. ExaCS runs in Oracle's cloud regions, so your data leaves your premises and sits in Oracle's data centre. ExaCC runs in your data centre, so the data never leaves your building, while Oracle reaches in over a secure connection to manage the system. If you have a hard requirement that data must remain on your own premises, whether for regulation, data residency law, or contractual reasons with your own customers, ExaCC exists precisely to satisfy that requirement while still giving you a managed, cloud style consumption model. If you have no such constraint, ExaCS removes the burden of hosting hardware entirely.

What they share

Because both are Exadata, they share the architecture that makes Exadata valuable: the split between database servers and intelligent storage servers, Smart Scan offload, Hybrid Columnar Compression, the flash and persistent memory tiers, and the internal fabric. A workload that performs well on one will perform well on the other, assuming equivalent configuration. Both support Real Application Clusters for high availability, both support Data Guard for disaster recovery, and both are patched and maintained by Oracle to a large degree. The database experience for developers and DBAs is effectively the same. This is why the choice is rarely about capability and almost always about deployment model.

Where they diverge

The differences are operational and commercial rather than technical. Connectivity differs, because ExaCC needs a reliable link between your data centre and Oracle for management, while ExaCS is reached over the public cloud network. Latency to your applications differs, because ExaCC sitting in your own building can be closer to on premises applications than a cloud region would be, which matters for chatty workloads. Billing differs in its details, though both follow a consumption style model for enabled cores. Data centre responsibility differs entirely, because with ExaCC you still provide the space, power and cooling, while with ExaCS Oracle handles all of that. And the surrounding cloud ecosystem is richer for ExaCS, because it sits natively alongside the rest of OCI, whereas ExaCC integrates with OCI services across the link.

How to choose

The decision tree is short. First, do you have a binding requirement that data must remain in your own facility? If yes, ExaCC is the answer and the rest of the comparison is moot. If no, the question becomes whether you have applications on premises that need very low latency to the database, in which case the local placement of ExaCC may still win, or whether you are cloud native or moving that way, in which case ExaCS is the cleaner choice because it removes hosting entirely and sits alongside the rest of your OCI estate. Cost should be modelled both ways rather than assumed, because the inclusion of data centre costs in the ExaCC equation, which you bear separately, changes the comparison.

Sizing the platform follows the same method regardless of which form you choose, and we cover it in sizing Exadata Cloud Service. The performance you can expect is likewise the same, as discussed in Exadata Cloud Service performance. And if you are moving an existing database onto either platform, the migration approach in migrating to Exadata Cloud Service applies. The ExaCC variant in particular is explored in Exadata Cloud at Customer explained.

The decision is rarely reversible cheaply

One reason to get this right early is that switching between ExaCS and ExaCC after the fact is a migration, not a setting change. Moving from one to the other means relocating data and reconfiguring connectivity, which carries the same effort and risk as any database move. That makes the upfront analysis worth doing carefully. The good news is that the decision is usually clear once the data residency question is answered honestly, because that single constraint resolves most cases. Where it is genuinely open, modelling both the cost and the latency for your specific applications will settle it.

Our implementation and migration practice works through this decision with clients regularly, and the independence matters here because the recommendation should follow your constraints and economics rather than a preference for one deployment model. If you want help framing the ExaCS versus ExaCC choice against your own data residency, latency and cost picture, an assessment is the place to start.