As 2012 came to a close I tweeted
Major talking point for 2013: the difference between databases in the cloud, and cloud databases
— Matt Aslett (@maslett) December 21, 2012
NuoDB’s 12 rules appear pretty sound to me – in fact you could argue they are somewhat obvious. This is actually to NuoDB’s credit in my opinion, in that they haven’t simply listed 12 differentiating aspects of their product, but 12 broader requirements.
Either way, I believe that this is the right time to be debating what constitutes a “cloud database”. Database on the cloud are nothing new, but these are existing relational database products configured to run on the cloud.
In other words, they are databases on the cloud, not databases of the cloud. There is a significant difference between spinning up a relational database in a VMI on the cloud versus deploying a database designed to take advantage of, enable, and be part of, the cloud.
To me, a true cloud database would be one designed to take advantage of and enable elastic, distributed architecture. NuoDB is one of those, but it won’t be the only one. Many NoSQL databases could also make a claim, albeit not for SQL and ACID workloads.
This isn’t a matter of SQL versus NoSQL, however. We’ve seen companies building their own next-generation database platforms deploying NoSQL and SQL technologies alongside each other for different workload and consistency requirements. Where the SQL layer falls down is the inability of existing relational databases to support elastic, geographically distributed cloud environments.
NuoDB believes it has a solution to that. So too do others including GenieDB, Translattice and VMware. Meanwhile Google’s F1 and Spanner projects have legitimized the concept of the globally-distributed SQL database.
Either way, the era of the relational cloud database – rather than the relational database on the cloud – has begun.