At the MySQL Conference and Expo this week, we've seen new storage engines popping out of the woodwork and it caused me to wonder at what point MySQL went from being a product to a platform. From a technical perspective, you could argue that MySQL has always (e.g. for at least 5 years!) been a platform, since it's enabled plug-in features and storage engines since the early days. Heck, Arjen wrote about it back At the MySQL Conference and Expo this week, we’ve seen new storage engines popping out of the woodwork and it caused me to wonder at what point MySQL went from being a product to a platform. From a technical perspective, you could argue that MySQL has always (e.g. for at least 5 years!) been a platform, since it’s enabled plug-in features and storage engines since the early days. Heck, Arjen wrote about it back in 2004! The pluggable storage engine API become increasingly important in recent years as people began extending MySQL in many different directions. The virtue of the storage engine API is that they could do this innovation on their own terms, without making the MySQL server team a bottleneck. If every storage engine enhancement had to be reviewed and approved by MySQL, innovation would be much slower. The beauty of a modular architecture was that it enabled these enhancements to happen in parallel without requiring our blessing and sometimes without our knowing! MySQL is not the first or even the most modular open source product. Obviously, Apache, JBoss, Eclipse, Firefox and many others demonstrated the benefit of modularity much earlier (and perhaps even better) than MySQL. But MySQL’s pluggable storage engine architecture is unique in the DBMS industry, where most products were conceived of and designed 20 or more years ago and have a monolothic architecture. And of course, if its a closed source offering, it may not be possible for anyone outside the vendor to make any enhancements. I remember in my first year at MySQL, our director of architecture Brian Aker was always telling me we should promote the pluggable API. And later when I worked more closely with Engineering, he and other developers on the server team would tell me we needed to make the server more modular and have lots of different ways of having plug-ins. While I don’t think anyone was against this type of modularity, it took on a whole new level of importance when Oracle acquired InnoDB back in 2005.Then it became crystal clear that the plug-in storage engine API was vital to MySQL. By this time there were half a dozen or more different storage engines, including MyISAM, InnoDB, Archive, Federated, CSV, etc. And we knew some customers were creating their own custom storage engines. But that fall and through the MySQL User Conference in 2006, we really began promoting the storage engine API. Amazingly enough, we started seeing more and more innovation happening in the community and among partners in our ecosystem.One of the first new engines developed outside of MySQL was PBXT by Paul McCullagh of PrimeBase. He had written the first version of a high-speed transactional engine in a matter of months. Since then, PrimeBase has also developed a new engine for Blob Streaming. Paul is giving two talks at our conference this year on these engines. InfoBright, KickFire, and Nitro EDB are all targeted at high-speed datawarehousing. And there’s new engines under development by companies including Tokutek and ScaleDB. ScaleDB is designed by a top-notch team that includes Vern Watts, the original architect of IBM’s IMS database management system. Vern worked at IBM from 1968 – 2004 when he retired. The photo below is with myself, Vern and Moshe Shadmon, CEO of ScaleDB.And of course, Oracle has renewed the InnoDB agreement with MysQL and they continue to enhance InnoDB with new features, including the latest plug-in version announced this week. MySQL has really become a platform for innovation. And as folks at Sun have often said, “Innovation happens elsewhere.” It’s great to see this happening in the MySQL community. Open Source