“About five years ago I started to notice an odd thing. The products that the database vendors were building had less and less to do with what the customers wanted.” – Adam Bosworth, December 29th, 2004
“Have you ever wanted to know what would happen if you had taken a different direction?
A number of months ago I was on the phone with the Rackspace CTO talking about Memcached and Gearman, and the work I am doing there. He had asked me if I had ever thought about creating a slimmed down version of MySQL to work with them.” – Brian Aker, July 22nd, 2008
Three years ago come November, I put the following question to Marten Mickos during an OSBC Q&A session: are you worried that some of the features introduced in MySQL 5.0 such as stored procedures, triggers, and so on will work against scalability by pushing business logic back to the database, as Adam Bosworth discussed? His answer was that he wanted customers to have the choice to use or not the features in question, rather than denying them that via the product direction.
The logic was understandable, as MySQL was pushing more into the applications space and increasingly being deployed alongside of – or in some cases, in lieu of – traditional commercial databases. Traditional commercial databases that had, among other things, features such as stored procedures and triggers.
Still, I did wonder what if. Particularly as I spoke to more and more startups that lamented the inability of relational datastores to provide simple features such as high speed, high scale text search.
Which of course is not the use case that Drizzle is aimed at. But many of the features added to MySQL that Adam and other developers had little to no use for are indeed the target of the newly announced project. As Krow puts it: “Stored Procedures, Views, Triggers, Query Cache, and Prepared Statements are gone for now.”
This project will undoubtedly be controversial in some quarters, if only because it is as Monty bluntly allows, a fork. Even those less concerned with the fact of the fork might see proof in its existence that MySQL is approaching Netscape-like bloat.
Personally, I see the project in much the same way that Brian discussed it on stage at OSCON this morning: a fundamentally different product aimed at a fundamentally different audience. Too often in this industry we try to please all the people all the time with the same product. But the simple fact is that the users that are deploying MySQL as a back end for, say, CRM applications have very different needs and expectations from those building high scale web and/or cloud based offerings. Very, very different needs.
As a smaller entity, however, it would have been difficult for MySQL to permit the pursuit of what at least initially will be a niche product aimed at a niche audience. Even if the niche may well prove to be the future of application development. Which is why it’s understandable that the reaction to the question posed by Tim O’Reilly this morning – “how has the acquisition by Sun gone, from your perspectives?” – were generally positive. The rumors and financial questions aside, Sun has more resources at its disposal than did MySQL prior to its acquisition. By an order of magnitude or two. Thus, Drizzle is blessed and born. On Canonical’s infrastructure, as an interesting aside.
The initial design goal – cut everything non-necessary – is obvious and has been discussed, but two other design decisions are worth noting.
First, the project is characterized not as a product of Sun/MySQL, but an independent open source (GPLv2) project of its own. What this means in practical terms will depend largely on the governance, which seems to be mostly ad-hoc at the moment. But certainly it will be viewed by some as a reaction to the MySQL model, which generally precludes outside contributions in favor of its commercialization and licensing model.
Second, Drizzle is, to a certain extent, the MySQL storage engine model pushed to its limits. While MySQL traditionally has preserved both customer choice and partner potential via its pluggable storage engine setup, that’s the only real area of flexibility in the core product. Drizzle, on the other hand, aims to be a microkernel type approach, in which virtually everything is an extension. A plug-in, if you will. It will be interesting to see how the architectural model popularized and epitomized by a consumer product in Firefox fares in the world of a high end, high scale datastore.
Will the project succeed? Who knows, it’s far too early to make that kind of an assessment. But certainly it will find a market and it will find interested developers, so I wouldn’t bet against it. Even if it promises no compatibility with its parent project.
What I’ll be watching for personally, however, will be not what they cut away, but what they can add. Because four years after Adam publically sought a new kind of database, we’re still looking. If stored procedures, views, and triggers are out, could dynamic schema, dynamic partitioning and modern indexing be in?
I have no idea. But it’ll be interesting to see.
Disclaimer: Sun is a RedMonk client, as was MySQL prior to its acquisition.
