Curator's Note: The content of this article was originally written by Bob Wiederhold over at the Couchbase blog .
Over the past couple of days a number of people have asked my opinion of the latest MySQL 5.6 release. For those who haven’t seen the news, Oracle announced its first major MySQL release in two years. Since NoSQL has grown rapidly in key markets where MySQL has historically been strong, I guess it’s not surprising that Oracle focused a lot of attention on addressing weaknesses that have made NoSQL such a big success. Tomas Ulin, VP of MySQL Engineering, even goes so far as to say that “MySQL can combine the best of both worlds” and “you no longer need two databases.”
Tomas and MySQL’s view of the database world seems to be that it will be no different than what it’s been for much of the last 40 years – mainly that relational technology can do it all and is the right technology for every need.
We don’t believe that. We believe we’re rapidly moving to an era where multiple database technologies are available to application developers and they will pick the right database for their particular use case and requirements. Each technology will have its inherent strengths and weaknesses and provide a very different set of tradeoffs to pick from. Sometimes a relational technology like MySQL will be a better fit (we certainly don’t believe relational technology is going away). Other times a document database like Couchbase will be the right fit.
This is why I don’t think MySQL 5.6 will have any affect on the rapid growth of NoSQL. The reason NoSQL is taking off isn’t because it has a hot feature or two. It’s because it has made a fundamentally different set of architectural choices and tradeoffs that many app developers prefer for the kinds of applications they’re developing today. Adding a feature to a relational database as a response to what people say they like about NoSQL isn’t going to change these fundamental differences.
For example, relational technology is fundamentally a schema-based technology of tables, rows, and columns. Adding a capability like the new online data definition language (DDL) in MySQL 5.6 to make it easier and less time consuming to change your schema doesn’t make a relational database schema-less. Nor does it address the fact that many developers find it far more intuitive and productive to work with documents (objects) in a document database than the tables in a relational database. So while this feature may be helpful to developers who have selected relational technology for its fundamental tradeoffs, it will do nothing to slow the wave of developers who have moved to document (or other) NoSQL databases for their fundamental tradeoffs.
Likewise, with MySQL 5.6's new memcached API, it might make it easier for developers to access data using the classic get and set APIs, but the implementation is only skin deep. The data being stored still gets mapped to tables and columns at the storage tier. Developers still need to define their table schemas before using these APIs, which means that they still do not get the schema flexibility web applications need. Shredding data that is unstructured – and constantly changing in structure – so that it fits into tables and columns is a forced and inefficient approach.
As a side note it’s curious that the MySQL team seems out of step with other parts of Oracle. While the MySQL team seems to be convinced MySQL can do it all, Oracle’s NoSQL team seems to feel differently and is busily trying to catch up to NoSQL leaders like Couchbase, MongoDB, and Cassandra with their own NoSQL product. If relational technology is a one size fits all technology, why is Oracle itself making such a big investment in developing its own NoSQL product?
What we see is a whole new wave of applications that have very different requirements than applications had just a few years ago. More often than not they are cloud-based, need to support a huge and dynamically changing number of users, need to store huge amounts of data, and need a highly flexible data model that allows them to adjust to rapidly changing data capture requirements and process lots of semi-structured and unstructured data. The fundamentally different architectural decisions embedded in NoSQL technologies – along with the easy scalability, consistently high performance, and flexible data model advantages (along with all the other tradeoffs) NoSQL provides – are turning out to be a better fit for an increasing number of these applications.
That doesn’t mean MySQL (or relational databases) will go away or won’t play a significant role in the database industry in the future. It just means developers will have more choice (always a good thing) and that some very powerful trends are very well aligned with the strengths of NoSQL technology.