Is Oracle RAC Really Obsolete? Insights from Chinese Distributed Database Trends

Oracle RAC: Historical Context and Architectural Limits

Oracle Real Application Clusters (RAC) implements a shared‑storage architecture. Early versions struggled to scale beyond eight nodes and typically handled up to ~100 TB of data, leading some to label it a legacy technology.

Pre‑RAC Alternatives and Early Performance Factors

Before RAC, Oracle Parallel Server (OPS) and VAX/CLUSTER systems provided parallel access using distributed locks. VAX/CLUSTER could achieve ~70 MB/s over a CI coupler, allowing any node to access the database concurrently. However, OPS on 10 Mb networks suffered from high latency and inefficient dirty‑page handling.

RAC Introduction and Technical Innovations

Oracle introduced RAC in 9i, replacing disk‑based dirty‑page writes with network‑transmitted CURRENT_BLOCK, dramatically improving concurrency. RAC was designed to overcome Oracle’s scale‑up limitation by enabling horizontal expansion.

Scalability Constraints

Increasing node count (2, 4, 8) can expose network and I/O bottlenecks, especially for ultra‑high‑concurrency workloads.

Traditional shared‑storage designs limit effective scaling without high‑performance interconnects.

Hardware Advances Mitigating Earlier Concerns

Modern data‑center networks (10 Gb, 40 Gb, 100 Gb) and SSD storage have alleviated many performance worries that previously constrained RAC. These improvements reduce latency and increase throughput for inter‑node communication and shared‑disk access.

Oracle’s Strategic Shifts

Oracle briefly explored sharding in 12c, but by 2019 refocused on RAC‑centric architectures.

At the 2019 Oracle OpenWorld, Oracle announced the “Coverage Database” concept, borrowing ideas from mobile‑app user experience to simplify failover and management.

Recent Domestic (Chinese) RAC‑Inspired Products

Several Chinese vendors have announced RAC‑style solutions in the past year:

达梦 (DM) DSC – deployed in production for select customers.

优炫 (Yoxuan) SuperRAC.

人大金仓 (Kingbase) upcoming shared‑storage multi‑read/write product.

高斯 (Gauss) RAC version under development.

虚谷伟业 (Wanli Open‑Source) in collaboration with 华为 (Huawei) – shared‑storage multi‑read/write MySQL.

Primary Use‑Case: High Availability vs. Scale‑Out

Most Oracle RAC deployments prioritize rapid failover and sub‑second reconfiguration after a node loss, offering higher availability than many distributed databases that may experience several seconds to minutes of downtime.

Conversely, many distributed‑database adopters over‑engineer hardware to avoid single‑node bottlenecks, often resulting in higher stability but not necessarily better performance.

Changing Application Landscape

Modern data architectures separate OLTP and OLAP workloads, employing data lakes, big‑data platforms, and real‑time warehouses. This reduces the pressure to scale OLTP systems indefinitely and diminishes the need for pure scale‑out solutions.

Conclusion

Evaluating RAC’s relevance depends on matching workload requirements with its strengths. For enterprises that need fast, automatic failover and can operate within the current hardware capabilities (high‑speed networks, SSDs), RAC remains a viable high‑availability solution rather than an obsolete technology.