Many MySQL critics have complaint about the lacking of key features, scalability and standards compliance. They also often complain about users who fall for MySQL's successful marketing, short of blaming the inherit evil nature of the universe why such inferior technology is so popular.

While MySQL has been catching up on all of the above mentioned fronts, it cannot be denied that one of its key strength's is its active community. While some will argue that this community was a direct result of giving the masses the features they needed, instead of clobbering them with features that would just overwhelm these often self educated people. Others might simply attribute this to their effective marketing machinery. However even today MySQL attracts new users even though the product has become considerably more complex. This is probably due to its clear dominance as the OSS database of choice. At the same time MySQL is now able to make in roads into the infamous “enterprise“.

A brief excourse. MySQL sets itself apart from other databases by the concept of storage engines, which let you choose from a wide range of features (or missing features) to be able to tune the feature set and performance for the exact needs of an application. While MySQL fan boys sometimes think that this means that other RDBMS lack such flexibility entirely the key feature here is modularity. This is one of the main aspects which is behind the success of OSS software. Commercial vendors want to bundle things as much as possible, sticking features into the core of already overdeveloped products. With MySQL 5.1 this storage engine concept will be enhanced to allow “pluggable” storage engines. This means that storage engines now do not need to be compiled in anymore.

This is a significant milestone, because it makes MySQL finally the perfect technology platform (a euphemism for marketing platform) for producers of specialized and/or niche database products. This means that when MySQL AB scoops up another Jim Starkey they can get the new technology into the hands of their users much more quickly. The recent announcement from SolidDB is therefore only an indicator of things to come. This way MySQL will solicit companies to open source (GPL to be specific) their IP in order to use MySQL as a marketing platform. Similar to how the Eclipse foundation works. Note that I am not entirely sure if I like what the Eclipse foundation is doing.

However, what will be interesting to see from an OSS standpoint is if anyone then takes that next step and assembles the best of all into a single GPL'ed storage engine. Obviously this would be of little interest for MySQL AB as they require the ability to license all the technology they support for their proprietary customers. So maybe eventually OSS users will get a better MySQL and their proprietary customers. So maybe the glass is more than half full after all.

Hi Lucas!

Great article with some fantastic points. You are absolutely correct that one of MySQL's greatest (if not *the* greatest) strengths is our user community. However, I think you may have overthought the pluggable storage engine concept as a marketing ploy :) In fact, the modular nature of MySQL's storage engines has been around for quite some time now as you know, and the pluggable storage engine API is an attempt to make the storage engine layer more modular, standardized and easier to use. While it may have added benefits of allowing the sort of quick-to-market facility of bringing new storage engines into the MySQL fold, the storage engine API and layer was not intended to address a marketing concern, but rather a technical one.

Different storage media, filesystems, and data types require fundamentally different strategies in both retrieval and storage of data on disk. The storage engine layer and API is an attempt to allow a modular approach to the storage of data so that various filesystem advantages, storage media quirks, and data type specifics can be addressed in the storage engine layer, without cluttering up the entire server architecture.

So, the question will never really be "if anyone then takes that next step and assembles the best of all into a single GPL'ed storage engine" because that's not the point of the storage engine API. The point is to provide the ability to specialize storage engines for very defined purposes, not to create a "best of all" engine. The trick to having a "best of all" scenario, from an architectural perspective, is to pull pieces and parts *out* of the storage engine that belong on a higher level, therefore allowing *all* storage engines to share common functionality. Such a case was made for foreign key constraints (not transaction safety, but referential integrity) and that functionality is currently being developed in MySQL at a higher level than the storage engine, so that all engines can benefit from it.

Just my two cents :) Hope this clears up some things...

Jay Pipes
Community Relations Manager, North America, MySQL

p.s. Will you be attending the UC by any chance next week? It would be great to meet up if you are...

Yeah, I did not really mean "one storage to bind them all", but I do expect there to be a certain overlap that could let to the creation of one or two technology-wise from dual licensed solutions cherry picked storage engines that could provide superior performance/features.

Lukas,

Good comments! I think the key in your message and in this topic in general is "the key feature here is modularity".

Every time we have made MySQL more modular, we have received more contributions. There is always a risk that modularity makes a system slower, so you have to create modularity carefully, but other than that it is one of the best benefits of open source.

Marten Mickos, MySQL AB