A decline for Oracle over the next 15 years is inevitable. It will be impossible to sustain the RDBMS-only paradigm against all logic as the new wave of databases lumped in under NoSQL and big data takes over. Oracle is responding with partnerships, and it already has a NoSQL database, but it's difficult to imagine a transition that leaves Oracle's revenue stream intact -- smells almost like Novell, circa 1996.
Yet the RDBMS will take its time to fade. The reason? Aside from the obvious -- it's an entrenched technology -- the advantages that made the RDBMS ubiquitous in the first place are going to keep it around a bit longer.
[ Harness the power of Hadoop with InfoWorld's 7 top tools for taming big data. | Find out which database works best for you in InfoWorld Test Center's survey, "NoSQL standouts: New databases for new applications." | Follow the latest issues in software development with InfoWorld's Developer World newsletter. ]
It may surprise you that I don't consider "transactions" to be one of those advantages. They've been overrated for some time. It's absurd to purport that a transaction, which must be too fine-grained to be useful across multiple request/response cycles, is an indispensible tool for most applications. Moreover, there are other ways to assure reasonable consistency.
The key advantage of the RDBMS, rather, is standardization. The history of relational databases has proven that even a poor job of standardization can create a market better than none at all. Indeed, standardization is the key obstacle to the takeover by the new breed of databases.
A new era for data
A transition to NoSQL (which I prefer to call NewDB) is inevitable. The relational database was created in an era of slow 10MB hard drives and low expectations. NoSQL is the stuff of the Internet age.
NoSQL has been created for an era when storage is cheap, while performance and scalability expectations are high. It's written for an era of digital hoarders. Current business, marketing, and information technology trends have ensured that I am now fully aware of exactly what Kim Kardashian likes and how much you like her. I'm not sure why I need this information, but there it is, and it must be analyzed.
We also live in an era when even as the market is improving, internal IT departments of brick-and-mortar companies are being sized up for outsourcing. The demand for the skilled expertise of those who care for and feed Oracle databases is likely to be forcefully abated. At most companies, the DBA is often no more than a skilled system administrator.
All of this means we need databases that do not require us to flatten the data and force it into a structure that the application must transform to use. We need databases that can handle today's massive data storage across as many disks as necessary to meet our needs for immediate gratification. A delay is simply not acceptable.
Yet there are obstacles to this transition. First, NoSQL lacks a dominant force. For the RDBMS, no matter which product you choose, you have at least a subset of ANSI standard SQL on which you can depend. For any of the new databases, you may have Pig, Hive, SPARQL, Mongo Query Language, Cypher, or others. These languages have little in common. For the RDBMS, you have some connector standard, at least, in the venerable ODBC. For NewDB, you must rely on a database-specific connector.