Skip to content

Drizzle from the Clouds

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.

Categories: Databases.

Tags: , , ,

  • Brian Aker


    Notice that Drizzle lacks the current Fulltext index support of MySQL. Do not be surprised if you see us do something very radical toward solving this problem.

    Also, Drizzle is just the first piece of a much larger project.


  • Adam Bosworth

    Brian and I usually see eye to eye :)
    And I’m 100% in support of Drizzle!!!

  • alphadog

    I agree with the premise that almost all ambitious applications tend to grow and grow so as to drive up market- and/or mind-share, but…

    Some questions/comments:

    1. A DBMS features “…Stored Procedures, Views, Triggers, Query Cache, and Prepared Statements…” and you don’t need them. So, you don’t use them. Is it still a performance hit then? How much? Enough to drive people to genuinely fork/create a niche database?

    2. You state that “…stored procedures, triggers, and so on will work against scalability by pushing business logic back to the database…” Now, I would argue that it is not the availability of the features doing that, but rather the lack of discipline in developers that would keep them from doing that. I keep the business logic in its layer, but I still need triggers and such to *guarantee fundamental integrity constraints of data* at the database layer. Of course, in a project where only one app layer hits one database, this can be forgiven. But in an environment where multiple teams with multiple apps hit the database, you need some integrity logic in the database to help prevent one errant developer from mucking it up for everyone, don’t you?

  • Pingback: Prosumer News

  • Pingback: tecosystems » Drizzle: Ahead of the Storm

  • Pingback: Oracle-Sun: an enterprise catastrophe | Irregular Enterprise |

  • Pingback: tecosystems » Microsoft Frees CodePlex: Now What? The Q&A

  • Pingback: tecosystems » NoSQL: Not Going Anywhere For a While?

  • Pingback: tecosystems » YourSQL, MySQL, and NoSQL: The MySQL Conference Report