I am wondering whether it is a good idea to convert a large D6 database of a community site (with 80% read 20% write and about 1300 qps, using MyIsam engine) from Mysql to MariaDB?

MariaDB seems to be highly desirable:

MariaDB is a database server that offers drop-in replacement functionality for MySQL. MariaDB is built by some of the original authors of MySQL, with assistance from the broader community of Free and open source software developers. In addition to the core functionality of MySQL, MariaDB offers a rich set of feature enhancements including alternate storage engines, server optimizations, and patches

However I'd like to hear first-hand experiences of fellow drupallers about the expected performance gains. I know that MariaDB uses XtraDB (InnoDB improved) storage engine by default. In fact my site slowed down significantly once I moved the Mysql database to InnoDB engine, so I am a bit unsure about the supposed performance gains.

Also I'd like to know about caveats (possible incompatible modules, etc) of converting to MariaDB.


  • 4
    IMHO I personally think that moving to MariaDB, or any other DB engine for that matter is irrelevant. Expensive queries are always going to be expensive queries. If you don't have a reliable static and persistent caching strategy in place, no matter what DB vendor you are using, your site is going down (and I'm talking from some personal experience here on some rather big sites). I think that optimizing your caching layer with Drupal's Cache API, possibly with a Memcached cache and Varnish on the front will go a much longer way than just swapping the DB vendor. Commented Dec 14, 2011 at 17:51
  • BTW, didn't post that comment as an answer because I would still be interested to see if anyone answers with some benchmarks. However I still say that even if those benchmarks proved MariaDB to be 2x faster, the site is still going down without a good caching strategy. Just sayin' Commented Dec 14, 2011 at 17:56
  • Well you are absolutely right about effectiveness of different caching strategies, and I use most of them. What I'm concerned here is the database part of the performance story.
    – alfish
    Commented Dec 14, 2011 at 21:07

2 Answers 2


MariaDB is the way to go.

I just can say my anecdote.
For a long time, I have noticed that mysql is my site's bottleneck. About a week ago, on a busy D6 (+2500qps) I moved from MySQL 5.5 to MariaDB 10 after reading that MariaDB uses, among other enhancements, 'xtradb' which is highly optimized for scaling compared with innodb. Also, I saw that MySQL 5.6 which is supposed to embarace many of the same enhancements is still not available in Debian repository, (not to mention that Oracle, the new owner of mysql, has been criticized as diverting from its open source pledges). It was also reassuring that Drupal.org is also using MariaDB since 2010.

So I did the bold decision to ditch MySQL. The transition was incredibly smooth. MariaDB is a real 'drop-in replacement. I just added MariaDB 10 repositories (generated by MariaDB website) to my Debian 6 and installed MariaDB. And voila, MariaDB takes care of the rest. Nothing else needed to be changed.

Since then, I've noticed a significant improvement in the database performance with less load, and no crash due to bad queries.


CAVEAT : This commentary is solely based on MySQL not Drupal.

I have personally worked with Percona Server and MySQL, not with MariaDB as of yet. Percona provides support for MariaDB, Drizzle, Amazon RDS, and other MySQL products.

I learned at Percona Live NYC that Percona gets the latest version of MySQL and injects 30,000 lines of C/C++ that is unique to its Performance Enhancements. MySQL (eh, Oracle) tries to keep up with its own enhancements of InnoDB.

Unless your Drupal website is very heavily trafficked, there is no decent performance difference you can feel or see. However, if you do have high traffic and you want to compare MySQL, Percona, and MariaDB, I have posted an article in the DBA StackExchange on how to go about doing this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.