You know, every couple of weeks an article like this comes up on HN or Slashdot predicting the end of the RDBMS. I don't deny that special purpose data stores can offer great performance improvements in some applications. But there is a reason that RDBMSs are celebrating their 40th birthday (as the article mentions). They are flexible, cheap (except for Oracle and DB2) and easy to manage.
My guess is that we will still be reading about the imminent death of the relational database another 40 years from now.
You could be right. But Stonebraker is not "just another guy" predicting the end of the era of the RDBMS. He's one of the guys who invented the RDBMS. If he thinks he's seen something better, well, I think it's worth at least taking a look.
He is selling something (he claims to be) better - Vertica.
I've no comment either way on whether it is, and I know who Stonebraker is and respect what he's done, but he has a vested interest here. Just like Netscape programmers needed to kill off their earlier work, Mosaic.
I agree. And he's been selling post-relational stuff for a while-- this is not a new observation on his part.
I'm not going to form an opinion on his word alone, but he's got big enough chops in my book to warrant taking what he says seriously, even if he has a vested interest.
Why do you make this assertion? Other than with a proprietary solution (e.g. Oracle RAC), what options are there to easily add/remove capacity on demand from an RDBMS?
Now, you can just add additional "shards" of a MySQL database, but that breaks the whole "R" of "RDBMS" (can't do joins across the shards). In addition, you're limited to a ring-style Master-Master replication scheme vs/ a grid/mesh. There's also MySQL NDB_Cluster engine, but I have never (to date) seen it in production (there are just too many limitations).
Proprietary solutions like Oracle RAC may scale on demand, but require a DBA team. The cost overhead offsets any savings gained through on-demand provisioning of resources.
Not to mention Oracle RAC (and even MySQL) aren't exactly friendly to commodity hardware (which is what both official cloud computing solutions and de-facto clouds used in high-tech companies' data centers are built on).
Oracle RAC is stupidly complicated to administer. You are correct in your statement that a RAC environment generally does require a DBA team and the cost overhead is significant. Further, Oracle has very stringent hardware and OS certification and you will not receive any support from Oracle on uncertified systems.
However, I would not associate it with the "cloud" movement/paradigm/whatever. It is a cluster (the C in RAC stands for cluster) with 2 or more instances sharing memory structures across a network. To add another node to the cluster is excruciating; I would not classify it as dynamically scalable - the hallmark of cloud computing.
I make that assertion because no one actually uses arbitrary amounts of scaling, "in the cloud" or anywhere else.
For many users, the primary benefit of cloud computing is the ability to go quiescent and not pay. For everyone, there's a benefit to handling various levels of load with usage based payment, but the active range is reasonably limited.
All this is well within the capability of a professionally administered RDBMS.
No, they are not. They can be stuffed into a cloud architecture, but they were not built with the cloud in mind. If you were to build a cloud database, from the ground up, what you would come up with would not look like a traditional RDBMS.
My guess is that we will still be reading about the imminent death of the relational database another 40 years from now.