MariaDB 5.3 is released as GA!

Congratulations to Monty Program and the many community contributors for releasing the GA version of MariaDB 5.3. We were in our annual all-staff meeting last week, so we are a little slow to blog about this and acknowledge the great work that has gone into MariaDB. Better late than never, I hope.

Before I discuss some of the improvements in MariaDB 5.3, let me mention a few things briefly. First, Peter and Ovais are doing a lot of benchmarking of specific MariaDB 5.3 and MySQL 5.6 optimizer improvements, and both of them look very good indeed. Peter will present the results in an “optimizer standoff” talk at the upcoming MySQL conference, and Timour and Sergei from Monty Program will present a tutorial on a similar topic. Make sure you don’t miss this conference! Secondly, remember that our support contracts cover MariaDB as a first-class member of the MySQL family of databases. Finally, High Performance MySQL, Third Edition mentions MariaDB in many places, so you can learn more about where its features might be helpful to you.

So what’s new and great in MariaDB as compared to MySQL? A lot of things. Here are some of the highlights:

  • Pluggable authentication so you can integrate MariaDB with external auth systems
  • Dynamic columns and virtual columns (they’re different) offer flexibility in schemas
  • Microsecond time resolution for DATETIME and similar time-based types, as well as microseconds in SHOW PROCESSLIST
  • Group commit for the binary log makes the server much faster with the binary log enabled
  • Faster queries through speedier joins, faster subqueries, and elimination of useless tables in joins
  • Thread pooling and a segmented key cache for improved scalability

That’s really just a sampling. A good starting point for learning more is the MySQL versus MariaDB wiki page. Note that a lot of these features are also available either in Percona Server or in the upcoming MySQL 5.6 in the same or slightly different forms, so there is some subtlety to this list. For example, Percona Server has the same group commit fix, and MySQL 5.6 offers microsecond timestamp support, as well as a lot of optimizer improvements. Even the standard MySQL 5.5 offers pluggable authentication; you just have to pay for the plugin if you want the official Oracle one; or you can use Percona’s PAM plugin.

MariaDB 5.3 isn’t the only exciting thing, however. MariaDB 5.3 is based on MySQL 5.1, but MariaDB 5.5 will be based on MySQL 5.5, so it will inherit a lot of the great improvements Oracle has made to the MySQL 5.5 release. This should help MariaDB be faster and more scalable, as well as adding a lot of nice features like less lock contention, better diagnostics, improvements to partitioning, and the addition of multiple InnoDB buffer pools. Best of all, MariaDB 5.5 might be here pretty soon — I caught this mention on the MariaDB IRC channel:

There are strong forces to ensure 5.5 GA before percona live in Santa Clare

This is great news indeed.

MariaDB really has come a long way. I remember that a couple years back I told Monty, “fix subqueries and you will change the world for a lot of MySQL users.” Well, that dream has come true, and now we have subqueries that execute inside-out, as a sane user expects them to do.

The new MariaDB release is a great development for MySQL users. Users now have more choice than ever — there are three great versions of MySQL that suit different needs and personalities, with different characteristics, and feature and performance improvements are moving rapidly forward for the MySQL world as a whole.

Share this post

Comments (17)

  • Twirrim Reply

    I’m looking forward to testing MariaDB with a particular use case that MySQL is struggling with (lots and lots of queries need rewriting to favour MySQL.)
    I do seem to recall MySQL finally got around to fixing that microseconds bug recently.

    March 5, 2012 at 9:20 pm
  • pcdinh Reply

    I hope that the next MariaDB will have lof of improvements over GIS features. Geolocation is increasingly becoming one of the most important features for mobile-enabled services. Unfortunately, most of current services are still powered by PostgreSQL and PostGIS

    March 5, 2012 at 11:03 pm
  • William Jimenez Reply

    Great to see more development activity for this project. How do you feel MariaDB differs from Percona Server (or does it at all)?

    March 5, 2012 at 11:44 pm
  • Henrik Ingo Reply

    Don’t forget that Timour and Sergei are giving a 3 hour tutorial on MariaDB 5.3 (and 5.5?) and MySQL 5.6 optimizers:

    March 6, 2012 at 5:17 am
  • Baron Schwartz Reply

    MySQL adds microsecond timestamp support in version 5.6, yes.

    MySQL is unlikely to be a usable solution for GIS anytime soon, because adding a new index type to InnoDB is probably a lot of work, and many changes would also be needed to the server itself. PostGIS is not only better than MyISAM’s GIS functionality, it’s better than some of the big expensive closed-source databases’ too. Sphinx is a technology to consider for some applications, though.

    I should write a blog post on the differences between MariaDB and Percona Server. They are fundamentally different and targeted towards very different use cases. But there are a lot of misconceptions, such as “Percona Server is just a set of patches” or “MariaDB has everything Percona Server has and more.”

    Henrik: mea culpa! I had completely forgotten that, and thank you for adding it in. I’ll update the text of the blog post.

    March 6, 2012 at 6:02 am
  • Henrik Ingo Reply

    Baron: On MariaDB vs Percona server, I sometimes see MariaDB having a group consisting of rather ignorant users. This is not supposed to say anything negative of MariaDB or its developers, or even the entire userbase as a whole, but just an observation of a type that I sometimes see and always surprises me. The archetype of this ignorant group is something like:

    * MariaDB is the new MySQL
    * Oracle’s MySQL is completely closed source or at least will be very soon
    * Has never heard of Percona Server

    It is possibly a European thing, and obviously such a person would not be reading your blog or planet mysql. (So you can’t do much to educate them either 🙂

    It would indeed be great to counteract such confusion with highlighting the real strengths of MariaDB.

    March 6, 2012 at 6:06 am
  • Baron Schwartz Reply

    I have noticed the same thing. I often see tweets like “Oracle has killed MySQL and made it closed-source.” Actually, people often say this to me in person at conferences. It’s too bad that this myth has somehow spread so widely. This is part of the reason I make some effort to blog and speak about Oracle’s real contributions to MySQL: I can’t stand when people are wrong on the internet 🙂

    Maybe the new High Performance MySQL book will also help counteract this myth.

    March 6, 2012 at 6:17 am
  • Jan Steinman Reply

    When will 5.3 be on github?

    When I do “brew install mariadb” it installs 5.2.8. When I do “brew update mariadb” it claims I have the latest.

    My main motivation for exploring mariadb is to use the OQGRAPH engine, which apparently is included with 5.3 but not 5.2.8.


    March 6, 2012 at 3:26 pm
  • Twirrim Reply

    On the subject of “Oracle has killed MySQL and made it closed-source”, whilst they haven’t made it closed-source, what they do appear to have done is shift a lot of bugs into their private tracker. Mark Callaghan noticed the change around this time last year: and it’s not improved since. With private tracking numbers and CVEs of increasing in vagueness, it’s harder for people to back-port patches.

    As an alternative Ubuntu has decided to just keep rolling out the latest version of MySQL for the moment and look to the possibility of switching to MariaDB (who keeps the whole process public) instead for the longer run. Upgrading to the latest version of MySQL is fine from a general perspective, but Oracle (and Sun before them) don’t just patch security exploits between releases, there are other things that get changed that might have unforeseen consequences (one of the reasons why distributions like to pin release versions.)
    Given MariaDB is MySQL with patches, I’m not sure quite how much that gains, or if MariaDB are basically doing that work and making it clear what is and what isn’t security fixes. I should spend a bit more time looking at MariaDB one of these days!

    March 6, 2012 at 6:53 pm
  • Henrik Ingo Reply

    Jan: The real MariaDB repository is on Launchpad at lp:maria. The git repository you mention must be a copy maintained by a 3rd party.

    Twirrim: Actually the Ubuntu discussion is one example of what I mentioned, though not totally as ignorant as my “archetype” above. It is interesting to note that before I pointed out that Percona Server even exists, it had not meen mentioned at all in the email thread where that was discussed. This is an observation that interests me, since it is completely different from what the core MySQL community focuses on – in fact I would say MariaDB is seriously underrepresented on places like planet mysql. (Ie possibly real MariaDB usage must be higher than what you’d believe from simply reading the blog posts on planet mysql)

    FWIW, MariaDB may very well be a good choice for Ubuntu and Debian, at least when there is a 5.5 version. It’s just that for someone who actively works on all things MySQL every day, it was weird to see a discussion where people are not even aware of the existence of Percona. It didn’t look like a very enlightened discussion. (But yeah, they weren’t saying Oracle is closing MySQL source code.)

    Personally I don’t see the problem distros have with the MySQL model. Contrary to common belief MySQL maintenance releases have never included new features as long as I have been involved – it is 100% bug fixes only. Possibly it is the case that distros would only want to patch security issues whereas MySQL also fixes non-security bugs like server crash, wrong result or just performance regressions. From my point of view the distros insisting on sticking to the original version they released and cherry pick patches on top of that might be worth questioning.

    March 7, 2012 at 12:26 am
  • Twirrim Reply

    Unfortunately that’s not true Henrik. Take for example the InnoDB plugin that has changed frequently throughout a release.

    You can see that even within MySQL 5.5 GA we’ve gone from InnoDB plugin version 1.1.4->1.1.8.

    Also, take a look at the changes in 5.5 from here: Quite a number of them have a “Functionality Added or Changed” section (e.g. 5.5.18, 5.5.17, 5.5.16, 5.5.14). Whilst the majority of them aren’t significant or liable to have any real impact on people, some of them are. For example from 5.5.10:

    “Incompatible Change: The shared library version of the client library was increased to 18 to reflect ABI changes, and avoid compatibility problems with the client library in MySQL 5.1. Note that this is an incompatible change between 5.5.10 and earlier 5.5 versions, so client programs that use the 5.5 client library should be recompiled against the 5.5.10 client library. (Bug #60061, Bug #11827366)”

    With Linux distributions like Debian or RedHat, a number of the compiled versions of various programs will have been complied against what comes at release, and would have been potentially broken by this unless everything had been re-compiled and pushed out to the repositories at the same time.

    March 7, 2012 at 2:01 am
  • Henrik Ingo Reply

    Twirrim: But the incompatible change in the client library could still be due to a bug that needed to be fixed. I doubt they mess with it just for fun. But yes, I certainly see why these kind of changes in the library are a showstopper for linux distributions.

    March 7, 2012 at 6:38 am
  • Jan Steinman Reply

    Henrik, sorry for the confusion — much of it on my part!

    The github build I was referring to is for package installation on MacOS using the “homebrew” package installer, since there is no official binary installation.

    I’ve updated the “brew” package to refer to 5.3.5-ga and included instructions for installing the OQGRAPH engine, which is not installed by default, as it requires the “boost” library. (Whew! And I thought I had nothing better to do on a nice sunny day… 🙂

    I now have a 5.3.5-ga server and client on Mac OS 10.6.8 that are talking to each other, that claims OQGRAPH is installed. Haven’t really done any tests yet…

    March 7, 2012 at 8:26 am
  • Olivier Reply

    Henrik, I’m now a user of MariaDB and here are my reasons :
    – Oracle is known for killing others softwares. They may not have killed MySQL completely at the moment, but it will happen someday in a way or another… Like said by others people in the comments : what is this private bug tracker things ? Don’t you think it’s weird to have an open source software and hide bugs like that ?
    – I could have used Percona Server because it seems great. But there’s a big “feature” missing for me : there’s no Windows version. Sure, our production servers are under Linux, but our develoment computers are under Windows and I prefer to use MariaDB under Windows and Linux than different softwares on different platforms.

    March 13, 2012 at 4:53 pm
  • Henrik Ingo Reply

    Olivier: The Windows support is possibly the most important feature of MariaDB. I’m really glad we got it going early on (I was employed there then). At least in 2010, over half of MariaDB downloads was for the Windows version.

    Regarding Oracle, you’re right, I’m not the big optimist on that front either (like Baron and others are). But MySQL is not closed source, and even the closed source modules Oracle recently published are nothing more than what could have been expected from MySQL AB itself – they always shipped some closed stuff. The bug tracker otoh is clearly an Oracle thing, we expected it to happen (InnoDB bugs were never public) and unfortunately it did happen.

    March 13, 2012 at 11:23 pm
  • Baron Schwartz Reply

    I’m not a big optimist on Oracle making open-source developers happy, but I just find it incredible that people think Oracle is going to “kill” MySQL after all the investments they’ve been making. There’s no evidence of killing, there’s just evidence of managing the product more like a piece of proprietary software in some respects, which is a no-brainer to me — I interpret that as Oracle wanting all of their development processes to be run consistently. The motive is quite clear to me, and although I would like it to be different, I’ve accepted it and moved on.

    I was a vocal critic of MySQL AB’s policies when I thought it would make a difference; these days I save my breath. I think my “optimism,” if you want to call it that, is just absence of criticism that I think is pointless. But at least I’m not inventing monsters where there is simply no evidence of them. To me, that’s far less realistic than politely complimenting Oracle for the good engineering they’re doing.

    March 14, 2012 at 4:31 am
  • Henrik Ingo Reply

    That is fair, and perhaps what sets you apart from others is that you remember to do it more often than many of us. Which is also true for MariaDB, as this blog post shows. (I intend to write one too, but I’m even more late than you…)

    It may have got lost, but that was also my original point: MySQL is not closed source (any more than it has been for years) and it hasn’t been killed. Other than that, there are also some good reasons to use MariaDB.

    March 14, 2012 at 4:46 am

Leave a Reply