Recently Oracle released it’s first update to MySQL in two years. This release was, at least in part, a response to the huge uptake of NoSQL databases and the move away from traditional structured databases for many applications. I was approached by Couchbase CEO Bob Wiederhold who believes that the release will have no real affect on the rapid acceleration of NoSQL adoption. Wiederhold perspective is that NoSQL has made a fundamentally different set of architectural choices and that those choices are attractive to application developers. Wiederhold wrote a blog post to state his views on NoSQL vs MySQL – it’s an excellent post and one which is good thought fodder for anyone running development project. And hey, if nothing else, at least NoSQL has a Gangnam Style parody video made about it – I don’t think MySQL can make that claim!

Why MySQL 5.6 is no real threat to NoSQL

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.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

3 Comments
  • At the Seattle Scalability meetup #SeaScale we’re not seeing new use cases implemented on MySQL. Sites like Expedia and Facebook born on SQL Server and MySQL are evolving to Cassandra.

    Columnar database for large business applications, Cassandra / HANA seem to be where the performance innovation curve is for non Glapar (G/L, A/P and A/R) business apps.

    Hazard a guess MySQL sticks around for donkeys years as the database for web apps as Btrieve P.SQL has for Windows apps from Sage for SMBs.

  • Stuart Speers |

    Thanks Ben. Couldn’t agree more with your points. It’s a changing data world and I don’t personally think trying to make a relational database manage unstructured data makes any sense. My biggest concern is always around making sure standards are created across all these new open options to allow for easier porting as needs change – a dream I know… But if open source is to lead the future can’t we get it right first time and not repeat proprietary lock-in challenges which all my customers hate!

  • Unlike SQL databases, because no queries need porting between different NoSQL databases, lock-in is better avoided.

Leave a Reply to Clive BoutlonCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.