Oracle Real Application Clusters (RAC) is one of the most expensive Oracle Database options — and one of the most over-deployed. RAC requires Oracle Database Enterprise Edition on every processor across every node in the cluster, with Oracle's Core Factor Table applied to each physical processor. A two-node RAC cluster running on modern 32-core processors can cost $1.2M+ in license fees before a single line of application code runs. Yet a significant proportion of enterprises running RAC are doing so not because they need RAC's specific capabilities, but because RAC was specified by a DBA team years ago and nobody has challenged it since. This guide explains the true cost of RAC, the licensing rules Oracle enforces, and the alternatives that deliver equivalent availability at a fraction of the cost.
Oracle Real Application Clusters is a Database Option — a separately priced component of Oracle Database Enterprise Edition that enables multiple servers to access a single shared database. RAC is not available in Oracle Database Standard Edition 2: it requires Enterprise Edition as the base. This is the first cost constraint: you cannot deploy RAC without EE, and EE costs $47,500 per Processor at list price, before the RAC Option itself is added.
Oracle RAC — listed as "Oracle Real Application Clusters" in Oracle's price list — costs $23,000 per Processor at list price. This is the Option cost, added on top of the Database EE base license. The total per-Processor cost for a RAC deployment is therefore $47,500 (EE base) + $23,000 (RAC Option) = $70,500 per Processor — before any Core Factor Table adjustment. Annual support at 22% adds a further $15,510 per Processor per year.
The counting rule that makes RAC particularly expensive: you must license every processor across every node in the RAC cluster. If you have a two-node RAC cluster, you count all processors on both nodes. If one node has 2 sockets × 16 cores (32 cores at 0.5 Core Factor = 16 Processors), and the second node is identical, your total Processor count is 32. At $70,500 per Processor, that is $2.256M in RAC license fees — plus $496,320 per year in support. This is for a two-node cluster using common modern hardware.
RAC Requires All-Node Licensing — No Partial Deployment Exemptions. Oracle's license rules require every processor in a RAC cluster to be fully licenced for both Oracle Database EE and the RAC Option. There is no provision for licensing only the nodes that are "active" or "primary." If a server is part of the RAC cluster — even as a passive standby node — it must be fully licenced.
Our Oracle Database Licensing Guide provides a complete reference for Database Options licensing, including RAC, Partitioning, Diagnostics Pack, and Advanced Security. The Oracle License Optimization service reviews every RAC deployment for right-sizing opportunities — identifying whether RAC's capabilities are actually being used and whether lower-cost alternatives can deliver the same availability requirements.
RAC's cost impact is routinely underestimated because enterprises focus on the initial license cost without fully accounting for the ongoing 22% annual support cost. Understanding the total 5-year ownership cost of a RAC deployment is essential for any technology refresh, cloud migration, or cost optimization analysis.
| RAC Configuration | Processor Count | License Cost (List) | Annual Support (22%) | 5-Year Total Cost |
|---|---|---|---|---|
| 2-node RAC (2×16 cores/node) | 32 Processors | $2,256,000 | $496,320/yr | $4,737,600 |
| 2-node RAC (2×32 cores/node) | 64 Processors | $4,512,000 | $992,640/yr | $9,475,200 |
| 4-node RAC (2×16 cores/node each) | 64 Processors | $4,512,000 | $992,640/yr | $9,475,200 |
| Active Data Guard (2-node, same hw) | 32 Processors (EE only) | $1,520,000 | $334,400/yr | $3,192,000 |
| List price calculations using Core Factor Table 0.5 for modern Intel/AMD processors. Negotiated discounts of 40–55% off list are achievable. Active Data Guard comparison uses Standard Data Guard (included with EE) at zero additional Option cost. | ||||
These figures use Oracle's published list prices. In practice, enterprises with negotiated Oracle Enterprise Agreements achieve 40–55% discounts on Database EE and Options licenses. Even at 50% discount, a 2-node RAC cluster on 32-core hardware costs $1.128M in license fees plus $248,160 per year in support — $2.37M over five years. This is the genuine cost that should appear in every DBA's architecture decision.
The support cost trajectory is particularly important. Oracle's 22% annual support rate applies to the net license value paid — and it compounds. If you are paying $996,320 in annual support today, a 3% Oracle support price increase (common in Oracle contract renewals) means $1.025M next year. Over a five-year Oracle agreement term, the total support cost on a $1M discounted license position can exceed the original license cost. Our Oracle Support Reduction service challenges the 22% rate as part of every optimization engagement.
We review every RAC deployment against actual workload requirements and identify whether RAC's clustering capabilities are genuinely needed or whether Active Data Guard, RAC One Node, or a cloud-native alternative delivers equivalent HA at lower cost. Our license optimization clients save an average of $640,000 per RAC cluster review.
Oracle RAC One Node — often overlooked in architectural discussions — is a single-node version of RAC that provides online server relocation and online patching capabilities at a significantly lower cost than full RAC. RAC One Node is priced at $10,000 per Processor (versus $23,000 for full RAC), and it still requires Database Enterprise Edition as the base.
The total per-Processor cost for RAC One Node is $47,500 (EE) + $10,000 (RAC One Node) = $57,500 per Processor — compared to $70,500 for full RAC. On a 32-Processor two-node cluster, this saves $416,000 in license cost if RAC One Node meets the availability and performance requirements. The 22% annual support saving is proportionate: $91,520 per year less than full RAC on the same hardware configuration.
RAC One Node is appropriate when the primary requirement is availability and patching flexibility, not RAC's core capability of concurrent access to the same database from multiple active nodes. Many enterprises deploy full RAC primarily to avoid downtime during patching or server maintenance — requirements that RAC One Node also satisfies, at 30% lower cost. The architectural decision between full RAC and RAC One Node should be driven by whether the application requires simultaneous connections from multiple nodes (full RAC) or simply requires zero-downtime maintenance and single-node failover (RAC One Node).
For many enterprises, Oracle Active Data Guard provides equivalent or superior high availability to RAC at a lower total cost. Understanding the trade-offs is essential for any RAC cost optimization program.
Oracle Data Guard (Standard Data Guard, included with Enterprise Edition at no additional cost) provides physical standby databases with automatic failover. Standard Data Guard's standby databases are not open for read access — they receive redo log data and apply it, but cannot serve read queries. Active Data Guard (a separately priced Option at $23,000 per Processor) allows the standby database to be open for read queries while still receiving and applying redo data from the primary — enabling query offloading and read scale-out in addition to high availability.
The key difference between RAC and Active Data Guard from an availability perspective: RAC provides sub-second instance failover within a cluster because the failed node's sessions can be re-established on the surviving nodes, which already have access to the shared database. Active Data Guard's failover requires the standby to become the primary, which typically takes 30–90 seconds with Oracle Data Guard Fast-Start Failover (FSFO). For applications that can tolerate a 60-second failover, Active Data Guard is often a sufficient and significantly cheaper alternative to RAC.
For enterprises whose primary RAC use case is read scalability — offloading reporting queries from the primary database — Active Data Guard at $23,000 per Processor may actually deliver better read scalability than RAC, because the standby can be sized differently from the primary. Standard Data Guard (free with EE) with Oracle Real Application Testing provides an even lower-cost HA architecture for workloads that can tolerate brief planned and unplanned downtime windows.
Running Oracle RAC on VMware is the single most expensive Oracle licensing configuration most enterprises encounter. The combination of RAC's all-node counting rules and Oracle's VMware policy — which requires licensing all processors in the entire VMware cluster, not just the VMs running Oracle — can multiply RAC license requirements by an order of magnitude compared to bare-metal deployment.
Oracle's position on virtualised environments is that VMware does not constitute a hard partition. This means Oracle's license counting rules require all physical processors across the entire VMware cluster to be licenced for every Oracle product running in any VM on that cluster. A VMware cluster with 20 physical hosts, where Oracle RAC runs on two VMs on two of those hosts, requires all 20 hosts' processors to be licenced for Oracle Database EE and the RAC Option. The two-host cost for bare-metal RAC becomes a twenty-host cost in VMware — a 10x increase in license exposure.
The combination is devastating for large VMware environments. An enterprise running Oracle RAC on two VMs in a 100-host VMware cluster, where each host has 2×32 cores, faces a Processor count of 100 × 64 cores × 0.5 Core Factor = 3,200 Processors of Oracle Database EE and RAC Option. At list price, this is $225.6M — a number that makes the Exadata and bare-metal alternatives look economically compelling regardless of other considerations. See our detailed analysis at Oracle Database Licensing on VMware.
Oracle RAC on Oracle Cloud Infrastructure (OCI) is available through Oracle's Exadata Cloud Service and Base Database Service (limited configurations). On OCI, RAC licenses are included in Oracle's cloud pricing — you do not separately purchase Oracle Database EE and the RAC Option; instead, you pay Oracle's cloud service rate per OCPU per hour, which covers the full RAC capability. For enterprises migrating RAC workloads to OCI, this changes the cost model from perpetual license + support to consumption-based cloud billing.
Oracle RAC is not supported by Oracle on AWS or Azure under BYOL. If you want RAC on AWS, you must use Oracle's license-included pricing through AWS Marketplace — AWS does not permit BYOL for Oracle RAC on its platform. This means enterprises moving RAC workloads to AWS either pay AWS Marketplace prices (which can be higher than on-premise BYOL costs) or evaluate RAC alternatives (Active Data Guard, PostgreSQL, Aurora) that are fully supported on AWS.
The cloud migration decision for RAC workloads is often the trigger for a broader RAC architectural review. When the cost of maintaining RAC on-premise is compared to cloud-native HA alternatives, and when the BYOL restrictions on major hyperscalers are factored in, many enterprises find that RAC was the right solution for 2010 infrastructure constraints but is not the right solution for 2026 architecture. Our Oracle Cloud Advisory service provides a complete cloud migration cost model for RAC workloads, including OCI, AWS, and Azure comparison scenarios.
The decision to remove or replace Oracle RAC is driven by three questions: Does the application actually require RAC's specific capability (multi-node concurrent access to a shared database)? Can the availability requirements be met by a lower-cost alternative (Active Data Guard, RAC One Node, Exadata)? Is the cost saving worth the migration effort and the risk?
Applications that require RAC's concurrent multi-node access capability are those that specifically exploit Oracle's Cache Fusion technology — applications with extremely high write throughput that benefit from cross-node cache coherency, or applications explicitly designed to distribute workload across multiple RAC nodes. This is a smaller category than most enterprises assume. Many "RAC-dependent" applications are RAC-dependent only in the sense that they were configured to use RAC — not that they actually need it. Removing RAC from a database that is only actively using one node 95% of the time is a straightforward optimization with zero application risk.
Our Logistics Database Consolidation case study documents a typical RAC right-sizing engagement: a logistics company running Oracle RAC on six clusters, where analysis showed four clusters had never experienced a failover event and were using only one node actively. Removing RAC from those four clusters and migrating to Active Data Guard saved the enterprise $4.2M in license and support over three years.
40 pages covering every Database Option — RAC, Partitioning, Diagnostics Pack, Advanced Security, In-Memory — with license rules, cost calculations, and right-sizing strategies. Download free.
Download Free →Stay ahead of Oracle's Database Options licensing changes. Weekly intelligence on RAC, Partitioning, Diagnostics Pack, and cost optimization strategies from active engagements.
Oracle Licensing Experts Team — Former Oracle licensing executives, LMS auditors, and contract managers, now working exclusively for enterprise buyers. Not affiliated with Oracle Corporation. About our team →