RAC's feature set, higher scalability, and high availability are part and parcel of many modern NoSQL databases. Consider Couchbase, which is adding a document database to its popular offering with the new 2.0 release. With full 24/7 support, we're looking at $4,500 per node. That adds up to $13,500, which is maybe three times what I paid for my motorcycle but less than I paid for my car. As for MongoDB, currently the most popular document database, we're looking at $4,000 per instance of mongod (you may end up running more than one instance per node since Mongo is single-threaded).
From an operational store standpoint, where quickly handling short reads and writes concurrently is the most important priority, RAC may scale to your needs, but at a price point that doesn't make much sense. Moreover, Oracle hasn't become any easier to maintain, and setting up for "five nines" availability would require a much more advanced system than I've priced out here.
For analytical systems, the cost will be higher. Fortunately, your need for RAC is much less urgent here because these systems tend not to be real time and mere replication is often sufficient. A Hadoop cluster might be more appropriate. Neither of the two largest Hadoop vendors seem to disclose their pricing publicly, but it's hard to imagine it's worse than building a RAC system of the same approximate scale.
Moreover, as we head to the clouds, what's more partitionable and affordable than autoscaling/autoprovisioning new nodes as traffic demands?
If you don't need RAC, maybe you don't need Oracle
A key advantage of the Oracle RDBMS is that if you design your schema and structure your queries just right, you can heavily parallelize analytical, ETL, and batch jobs. A possible corollary to "it's uncommon to write your software well" is that it's uncommon to design your schema well, especially if you're trying to have one master model of all of your data. But if your problem lends itself to this kind of parallelization, it probably also lends itself to MapReduce.
Even if you have a great fit for the RDBMS, you aren't doing some highly parallelizable star-schema crazy thing, and you're not using RAC, you can use a much less expensive RDBMS such as PostgreSQL or even SQL Server (which last I checked was about one-fourth of the cost). For operational systems, the best thing your RDBMS can do is manage concurrency and get out of the way while you try and hit the disk (or maybe the cache) as quickly as possible.
Nonetheless, Oracle will have a long tail, because it's entrenched -- and enterprise customers have undertaken ill-advised actions, like writing PL/SQL triggers. Migration will take time, and in some cases, spending a few hundred thousand dollars more is less painful than the cost of the refactoring.
But my original advice holds. Anyone looking at Oracle RAC for a new system should probably take a much deeper dive into NoSQL and their data problem. NoSQL is a RAC killer.
This article, "NoSQL is no Oracle killer," was originally published at InfoWorld.com. Read more of Andrew C. Oliver's Strategic Developer blog, and keep up on the latest developments in application development at InfoWorld.com For the latest business technology news, follow InfoWorld.com on Twitter.