Map of MySQL forks and branches

Last year Morgan Tocker published a graph of all MySQL forks when preparing course material on the topic. I've been preparing some material for Monty's keynote at the O'Reilly MySQL conference, and briefly touch the same topic so I have pictures too:

map of MySQL forks

MariaDB with other MySQL forks

I don't want to be a spoiler so I'll save the narrative until after the conference. But as you see these pictures are MariaDB centric in that they make the point that MariaDB includes most of the other stuff out there (all but Drizzle). I couldn't figure out how to make that point with everything in one image, so I made it a 2 step animation.

See you in Santa Clara soon!

Hi!

Ebay's work went into Drizzle (though we are likely to replace that engine soon). MariaDB is a subset of the MySQL branches, you aren't pulling in everything (which is sane, there is a lot crap in that tree no one wants).

One note about Drizzle's ancestor 6.0, we ripped out almost all of it in the end. There is a reason why it was a dead tree :)

Cheers,
-Brian

Hi Brian

Yeah, I actually had to go and check your old blog where you announced Drizzle, but it said 6.0 so that's what I went with. In MariaDB we are now doing the opposite. Igor, Sergey P and Timour are pulling back the unfinished features from 6.0, putting in some months of work and in MariaDB 5.3 we will finally have the fast subqueries and complex joins that I have already been selling to customers when at Sun :-)

As for the "Abandoned patches", they are everywhere. There is no way to draw arrows from every place to every other place. You can have Drizzle+PBXT too.

Hi Kostja

It is clear that MySQL is the "mother branch" of all the other forks and the first picture is supposed to even deliver that message. The work done inside Oracle is not intended to be seen as insignificant.

But, since the other forks base their work on a recent MySQL version plus add more patches that don't exist in MySQL, it logically follows that MySQL has the least patches, even if the amount of work done (in man-hours at least) is bigger than the others combined. So reading your opinion literally, I don't agree with it.

But that's what I'm trying to say. Even if MySQL is good, and includes your patches, the Facebook branch is still MySQL + new FB patches. The FB patchset may be small in comparison to what you take from the base MySQL branch, but taken together they are still a superset.

(Btw, as I chatted with Domas on IRC too: MySQL@Facebook isn't mentioned because I see it more as a source code branch - what patches used to be - than a fork intended for end users. On the other hand it is also not an abandoned patch, so couldn't list it in that cloud either.)

I am wary of claiming that patches, branches or forks are supersets unless that includes the good (new features, better performance) and the bad (new bugs). I am also wary of claiming that something is much better until that claim is also made by real-world workloads and the new software runs in production.

Note that I just received a MySQL error while posting this (MySQL server has gone away query). Which fork are you running?

So the above map is supposed to explain the relationships of forks in a "this includes stuff from that" manner. But it doesn't say "this" is better than "that", except for those who mainly like more features (or performance, which as Mårten always said, is a feature).

I'm well aware that you and many other database users are conservative and think that "more stuff" is at least suspicious, if not undesirable. This seems to also be why there is demand for the new Percona XtraDB Server, it has some of the Percona/XtraDB improvements, but not as much deviation from MySQL 5.1 as MariaDB has.

Suspicion of new software is practical not conservative. Anyone who isn't suspicious of changes has never run complex system software in production.

With respect to 'more is better' lots of claims have been made elsewhere that MariaDB is a better MySQL. Don't tell me, show me.

About the bookAbout this siteAcademicAccordAmazonAppleBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDistributed ConsensusDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLNyrkiöodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPParkinsonPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTransactionsTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube

Search

Recent blog posts

Recent comments