Sun's sudden acquisition by Oracle triggered a deluge of speculation
about the future of the company's free software projects: Java, OpenOffice,
VirtualBox, OpenSolaris, and, most of all, MySQL. Will Oracle kill it? Spin it off?
Keep its hands off? In light of this uncertainty, the discussion soon
shifted to the trickier question of what branch constitutes the
MySQL. The project has been forked multiple times — several even in
the past year. Considering that each competitor is led by a heavyweight
MySQL developer and has its own goals, how is a humble database
administrator supposed to choose?
Patch sets and proto-forks
The seeds of this confusion predate MySQL's acquisition by Sun, when
MySQL developers began to lose patience with MySQL AB's governance of the
project. Management had announced two branches, "enterprise" and
"community," in 2006, but soon began to miss scheduled binary and source
releases of the community branch. Worse still, community developers
complained that the company was trying to hide the enterprise branch code
— changing the release location between iterations.
In 2007, Jeremy Cole of Proven
Scaling took matters into his own hands, and set
up a public mirror of
the official "enterprise" releases as they appeared. Cole does not make
changes to the code released by Sun, although Proven Scaling does publicly
maintain its own set of patches and tools for
MySQL — as do several other database consulting firms and MySQL
One of those consulting firms is Percona, a web-development consulting
business that emphasizes its expertise in MySQL. Percona develops a
pluggable storage engine for MySQL called XtraDB.
XtraDB is an enhancement to the popular InnoDB engine, designed to work as a
drop-in replacement. It adds the ability to scale better on multi-core
hardware, use memory more efficiently, and adds more tune-ability and
releases do not remove InnoDB to replace it with XtraDB, but do include
patches to InnoDB. They also incorporate patches from other sources,
including Proven Scaling, Google, and Open Query. Source and binary releases, as well
as RPMs for Red Hat Enterprise Linux, are available for MySQL 5.0 and MySQL
Percona's patch set is documented on the
company's wiki. The patches include changes that add status variables,
more configuration parameters, additional I/O settings, dynamic memory
allocation, and alters mutexes and locks to improve performance on SMP
OurDelta was launched in October of
2008 by former MySQL employee Arjen Lentz (now at Open Query), and describes its mission as providing
"enhanced" MySQL builds for common production platforms. Its releases
build on Percona's, adding additional patches (some from Google and other
third-parties, some original work) and including additional storage
OurDelta maintains two builds, one stable and one bleeding-edge. All
stable releases so far have been for MySQL 5.0, and include the
storage engine. Upcoming work for MySQL 5.1 and MySQL 6.0 will add an enhanced version of InnoDB
from Innobase, PBXT, and FederatedX storage engines.
OurDelta makes source code
releases available as tar archives, and runs binary repositories for Red Hat Enterprise Linux and CentOS,
Debian, and Ubuntu.
OurDelta also documents its
significant patches. In addition to the Percona patch set, OurDelta
includes activity monitoring and reporting (per table, index, account, and
machine), improved logging, an option to kill idle database connections,
the ability to temporarily freeze InnoDB for backup purposes, and
improvements to speed up failover.
MySQL founder Michael "Monty" Widenius started his own fork in February
of 2009 after leaving Sun. At the time, he said
his reason for departing was dissatisfaction with Sun's development and
community processes for MySQL, which was not "a true open development
environment" that encouraged outside participation.
Widenius's fork is called MariaDB, and the only
major change is that it uses the Maria storage engine, which is
the focus of development. The rest of the code is regularly synchronized
with MySQL releases from Sun, and is intended
to be one hundred percent interoperable.
The Maria storage engine is an evolution of MySQL's default MyISAM
storage engine, and is designed
to duplicate the features found in InnoDB, notably crash recovery and full
transactional support. Maria and MariaDB are being developed against MySQL
5.1. Widenius expects the Maria engine to be a standard part of Sun's
MySQL 6.0 releases, but intends to keep developing MariaDB even after MySQL
6.0 is stable. So far, the project has released
source code packages and generic x86 binaries for Linux.
Widenius maintains a wiki page documenting the advantages
of MariaDB over Sun's unmodified MySQL, focusing on the features of the
Maria storage engine. Aside from the larger goals of crash-safety and
transactional support, he notes that using Maria as a storage engine should
speed up complex queries. In addition, MariaDB contains speed
improvements, the ability to use a pool of threads to handle queries
(rather than one thread per connection), and bugfixes not accepted by
Drizzle is the most distinctive MySQL
fork, perhaps better described as a complete refactoring. Drizzle is the
work of Brian Aker, long a preeminent MySQL developer. He announced the
project in July of 2008, saying that he disliked many of the changes made
to MySQL after version 4.1, and felt that there was a large market of users
that did not want them. Despite launching the fork, Aker continues to work
in the MySQL group at Sun.
Drizzle cuts the core of MySQL down to the bare minimum, using a
microkernel-and-modules approach. The goal is to create a slimmed-down,
optimized database targeting web infrastructure and cloud components.
Aker said that Drizzle will question the foundations of database design,
and is not intended to be SQL compliant. The FAQ emphasizes a "look
forward, not back" philosophy. For example, Drizzle targets
modern, multi-core hardware, modern compilers, and modern operating
systems. Similarly, the development team is not
interested in feature requests or in adding excised MySQL features back
in. Thus far, the project had made only source
code releases, and has noted that they are not yet stable for
The major Linux distributions all package Sun's "community" version of
MySQL. Sun itself provides free downloads of the community edition from the
web, evidently having learned a lesson from the 2007 uproar. Sun's official
packages are likely to be newer, given the release cycles of most
distributions, and to its credit Sun makes binary builds available for a
wide variety of processor architectures and distributions, including older
releases of those distributions. For most users, such a supported build is
usually the best choice. The Percona and OurDelta packages represent the
work of in-the-field MySQL consultants, and MariaDB is focused on the Maria
engine, but only experienced database administrators are likely to be able
to take advantage of the additional features they offer.
Still, it is telling that so much of the work done by the forks centers
around the InnoDB storage engine: the patches written by Percona and
OurDelta, Percona's replacement engine XtraDB, and MariaDB's replacement
engine Maria. InnoDB is GPLv2-licensed, but the copyright is owned by ...
Oracle. Oracle acquired InnoDB's creator Innobase in 2005. That
acquisition sparked a flurry of concern that the database giant would kill
the product, take it proprietary, or somehow use it against MySQL —
many of the same nightmare scenarios now speculated about the Sun purchase.
It is worth noting that in the intervening years two things have occurred:
Oracle has not killed or maimed InnoDB, and the open source
community has preemptively created its own innovative solutions, thereby
open source users and customers from disaster should Oracle take a step in
the wrong direction.
The real question is not which fork is the MySQL, but whether the
multiple patch sets and forks indicate sickness or health for MySQL as a
whole. Excluding Drizzle, all of the projects were started because someone
who cared a great deal about the future of MySQL saw something wrong with
MySQL's development process (and for its part, Drizzle was spawned by even
deeper dissatisfaction with the technical direction of MySQL). Surely that
much concern on the part of the community signifies health. There is no
telling which forks will prosper and which will fizzle out, but that depends
to a large degree on Oracle, and how it governs the project in the
to post comments)