What if

For the last 2-3 years, Brian Aker and I have had many discussions about how to refactor MySQL. Brian has been the one driving these discussions by asking why some things in MySQL were done in a certain way and in a true "what if" manner asked what would happen if we would do things in another way.

Being tired of not being able to get critically needed reconstruction work done in the MySQL server, Brian started to work on Drizzle to search for answers to these questions.

So what is Drizzle?
  • Drizzle is what MySQL would be with a more interactive community involvement in the design of the software itself, and had targeted website deployments.
  • Drizzle is a version of MySQL that is driven by Brian and the community, attempting to solve practical problems that a large group of MySQL users are facing.
  • Drizzle is a smaller, slimmer and (hopefully) faster version of MySQL; Features that the broad Drizzle community does not want or need are now removed or in the process of being removed (This includes stored procedures, views, triggers, grants, some non-pluggable storage engines and more).
  • Drizzle is the 3rd fork of MySQL server code base, but is the one that has (for now) the most developers working on it. The two other forks are:
    • The MySQL-5.1-maria fork, provided by the Maria team lead by me. (Brian did beat us when it comes to opening up the tree for outside development; We are still at least a month away from doing this).

Why is it that the people working on Drizzle are extremely enthusiastic about Drizzle?

This is because Drizzle solves many of the problems that MySQL's development has had for years:

  • It opens up MySQL development for the community; You no longer have to wait years to get your patches and resonable extensions into the server.
  • Critical bugs that have existed for years can finally get fixed as the development is no longer constrained by unrealistic release schedules that put artificial constraints on things that can be fixed.
  • Drizzle will put some MySQL server differentiation on a true test; A bit like Fedora does to RedHat.
  • Drizzle has created new excitement in the MySQL developer community; A lot of people seem to be very enthusiastic to work on it in a true community-oriented manner.
  • Developers working on Drizzle is doing drastic refactoring of the server, something that MySQL planned to do years ago but never happened.
  • Development decisions is again driven by people that are using the server daily; This will ensure that Drizzle will be faster and more stable than what can be done with current MySQL development model
  • Drizzle will target the MySQL core users, the web users, whose requirements have been ignored for years while the core MySQL developers have added features that they don't need.
  • In addition Drizzle will include the latest InnoDB code; You don't have to wait for MySQL 6.0 or go to the trouble of annually downloadoing and installing the InnoDB plugin from Oracle just to get access to the latest and fastest InnoDB version.

That said, Drizzle is not here to replace the normal MySQL server; Drizzle targets a limited but important market and will thus help us the enhance the MySQL based offerings. Think of Drizzle as the microkernel server around which other offerings/features can be developed.

Drizzle has no release schedule or timeline, but will follow a true open source and agile methodology of releasing early and releasing often; Brian expects that there will be a usable, reasonably stable version of drizzle within 3-4 months, but there are no promises.

Drizzle will also be of great help for the 'normal' MySQL developers; By looking at how Drizzle is solving things and by constant benchmarking against Drizzle, we will get a better insight into the weaknesses of the current codebase and have a better idea of what needs to be fixed; Friendly competition is good!

Drizzle is one of the good things that have been made possible by Sun acquiring MySQL. Brian has been working on Drizzle with the blessing and encouragement from Sun's upper management. We are finding Sun to be open and encouraging of innovation, this has been a good aspect of the acquisition.

My personal reaction to Drizzle is that I am very enthusiastic for this new kid on the MySQL block. I don't agree with everything that is done, but most things makes a lot of sense. I am looking forward to a lot of very interesting discussions about solutions in Drizzle that will help improve both MySQL versions.


Unknown said...

Borland did something similar to this when they forked Interbase a few years ago into Firebird which went open source.

My concern with Drizzle is
1) What transaction engine will be available? Innodb or Falcon?

2) What is the cost going to be to distribute applications with Drizzle? Is the licensing scheme going to be similar to MySQL? $595 per server or free if your source code is included? If so, then what is the incentive to using Drizzle for commercial applications?


Ronald Bradford said...

Great description. I'm encouraged to see your closing comment.

"I don't agree with everything that is done, but most things makes a lot of sense. I am looking forward to a lot of very interesting discussions about solutions in Drizzle that will help improve both MySQL versions."

Steven Roussey said...

Sounds great Monty! I'm glad to hear that none of the forks is frowned upon -- it keeps me believing in the whole community.

Stewart Smith said...

It would also be possible to call the MySQL Cluster Carrier Grade Edition (or telco) trees forks as well.

Monty said...

As far as I know, Drizzle will have InnoDB and Maria (the later as soon as Maria 1.5 stabilizes, which should take about a month).

Drizzle is targeted not distributed applications, like web applications. For these you don't need a license. I don't think there will be a commercial, dual licensed version of Drizzle.

Of course, you can always use Drizzle freely in your product if it's open source/free software or if you don't distribute Drizzle.