Earlier today I posted a Drizzle white paper we've been working on: Drizzle and IPv6.

We hope to publish more such white papers in the future, and focusing on features and architectures that are unique to Drizzle (altogether, or, as in this case, at least with regard to other MySQL forks). The IPv6 support was a nice feature to start with, since it is quite a simple thing on the one hand, but otoh it is (surprisingly) still a distinguishing feature that the family of "classic MySQL" forks don't have. Of course, it is also timely both because a) the IPV6 column type is new for Drizzle 7.1 and b) it was developed as part of Google Summer of Code 2011, and we are now approved for GSoC 2012 so it is a nice showcase for a new batch of students what can be done.

But while IPv6 is perhaps a small detail in all the things an RDBMS does, it also nicely captures the vision of Drizzle to be modern and fresh. The IPv6 networking support was implemented early on in 2008 as part of this agenda. It's perhaps not as grand of a project than massively modularizing the code base or removing mutexes in a quest to scale better on multiple cores, but it's one thing.

At the same time, it's not such a big deal. I don't expect lots of people to migrate en masse to Drizzle because it has support for IPv6 networking, when at the same time they might actually be needing features it lacks - from stored procedures to HandlerSocket, just to list an example each of both old school and trendy MySQL features. I fully believe MySQL will not have a problem implementing IPv6 when the world really, I mean really, needs it. So it's more just something to highlight the Drizzle personality than anything else.

In fact, showcasing new features and approaches may be Drizzle's biggest contribution to the MySQL space - at least to this day. In the case of IPv6 it's rather obvious that one day everyone will have to support it.

Update: It seems MySQL 5.5 does indeed support IPv6 networking, it's just not documented anywhere. See comments for handwaving. (It does not invalidate the point of this blog though, which was precisely that sooner or later the classic MySQL forks will fill also this gap, just like the ones I'm listing next.)

If we think of other recent advancements along the Percona-MariaDB axis, I can think of:

• Fixing InnoDB group commit. In Drizzle this just went away due to redesigning replication in a way that it doesn't do XA anymore (the binary log is inside InnoDB). Percona Server and MariaDB now have a fix created by Kristian Nielsen and MySQL 5.6 will ship with a different fix to the same problem (I believe it is done by Mats Kindahl).
• Pluggable authentication, e.g. LDAP authentication. It was in Drizzle a long time ago (in fact, only recently Daniel Nichter re-introduced something that resembles the familiar MySQL way). This Autumn Oracle published closed source modules for MySQL pluggable authentication, followed immediately by open source releases from Percona and MariaDB. Btw, Drizzle's approach still goes further. On the classic MySQL side the native authentication still takes the role of a proxy to all other alternatives (you still need to CREATE USER, essentially LDAP just becomes a way to sync your password) while in Drizzle all authentication alternatives are created equal. If you choose LDAP then users are created in LDAP only, there will be no user tables at all.
• Thread pool. Well, in fact Drizzle doesn't have a thread pool as far as I know, instead the refactoring work was focused on enabling good scalability to hundreds of client connections by really removing the locking that degrades performance. Also announced during last Autumn, and now first available in MariaDB 5.5 beta, the classic MySQL camp takes the approach of a thread pool. It's a bit of cheating really, as it doesn't clean up the locking issues MySQL has when going beyond 32 client connections, but instead it just acts as a gate keeper and makes sure only 32 (or another low number) threads are running inside MySQL at any given time. Cheating or not but apparently it works, so the end user should be happy nevertheless.

These were just a few examples I could think of where Drizzle is proud to have been "leading the way" but all the other MySQL forks nowadays provide a similar feature - hence there really isn't a big competitive advantage one way or another. It's more about different "personalities" or "spirit" between the projects which derive from their respective goals.

Speaking of Google Summer of Code, I got the email that Drizzle is accepted for this year again! We seem to be one of the 19 projects that don't yet appear on the 2012 GSoC listing, but hopefully by tomorrow you can already see us there. Meanwhile, if you're a student and interested, we have a wiki page with some information and project ideas.