Today SkySQL is changing its name to MariaDB Corporation. This is something that I had both anticipated and I think it’s a great step for MariaDB.

I wanted here to to share my thoughts on how this change affects the MariaDB community.

The short version: As the MariaDB Corporation is the main driving force behind the development of the MariaDB server and the biggest support provider for it, it makes sense to give it a name that clearly communicates this fact.  The name change doesn’t of course stop the company to continue it’s excellent support for MySQL.

For MariaDB users and customers, the name change should not affect them in any way, except that it will make it easier for them to find more information about MariaDB as there is fewer names involved.

For the MariaDB Foundation, there is no big change either. After all, the MariaDB foundation was created to protect the MariaDB server, not the MariaDB trademark as such. The longer version, for those who want more context, starts with some history.

After the Sun acquisition of MySQL AB, I started Monty Program to work on a branch of the MySQL code base named MariaDB after my youngest daughter. In 2010, I was one of the founders behind SkySQL, as an alternative service provider for Oracle MySQL customers. Last year SkySQL merged with Monty Program to increase the support behind MariaDB. As the adoption of MariaDB has grown, SkySQL’s business has evolved to provide products and services to over 2 million MariaDB users.

Talking about a company called SkySQL, that provides subscription services for MariaDB while also supporting MySQL, was becoming too complicated and confusing. To make things simpler, and reinforce the company’s focus, I both agreed and recommended that a name change was due.

Having the company using the MariaDB name will also help ensure that the company will focus on MariaDB and put even more development resources on MariaDB.

I assume that some people will wonder if the MariaDB Foundation is needed anymore?  I think it’s needed now more than ever to ensure that the MariaDB server is always guaranteed to be open for development by the community! The Foundation will continue in its role at the center of the open, independent and dynamic community that drives the adoption of MariaDB.  The Foundation will also need more paying members to be able to continue interacting with the ever growing external MariaDB developer community.

We’ve been working with the team at MariaDB Corporation (formerly SkySQL!) and have come to agreement on how the trademark will be used. Details of this will be published soon on

I continue to believe passionately that the world needs an open, actively developed relational database platform that is adopting to your needs and is better suited for modern web scale application development than other alternatives. MariaDB is that platform. We, the MariaDB developers and all other people at the MariaDB foundation and MariaDB Corporation, are all excited that so many of you are choosing MariaDB. We are all committed to making this choice a success.

MariaDB would not be what it is today without your support!  Thank you for this!

Download MariaDB 10.0.14

Release Notes Changelog What is MariaDB 10.0?

MariaDB APT and YUM Repository Configuration Generator

mariadb-seal-shaded-browntext-altThe MariaDB project is pleased to announce the immediate availability of MariaDB 10.0.14. This is a Stable (GA) release.

See the Release Notes and Changelog for detailed information on this release and the What is MariaDB 10.0? page in the MariaDB Knowledge Base for general information about the MariaDB 10.0 series.

Thanks, and enjoy MariaDB!


This blog is a follow up to my original blog in . First of all I would like to thank for all the comments I received. Based on the comments there was a concern if the differences seen on performance was due to different configuration setup. Furthermore, I did not know that there was a configuration variable to get similar multi-threaded flush mechanism on MySQL as there is on MariaDB. To find out if the different configuration variables or different defaults were the reason for different performance, I ran several rounds of new tests.

Test 1

Changing number of buffer pool instances or value of innodb thread concurrency do not seem to have significant effect on at least LinkBench benchmark performance results. However, changing the number of threads on flushing has an affect. Below I present results from both MariaDB and MySQL using page compression.  Lowest line is the original results already presented on .



Changing parameters had an effect and performance results from LinkBench benchmark improved. However the improvements are similar for both servers. Clearly, MariaDB still outperforms MySQL on this benchmark using this configuration. Below, is the full set of configuration variables used in this test.


While, I was still testing different configuration setups on the previous test an excellent blog on similar performance measurements were published on This blog contained again a different configuration (and naturally different hardware). Results were so interesting that I decided to try to repeat them.

I started from the results I obtained using uncompressed tables and in my system I have Intel Xeon CPU e5-2690 2.90GHz, 2 sockets, 8 cores using hyper threading, i.e. total of 32 cores. I use CentOs 6.4 and Linux 3.4.12. Storage is Fusion-io ioDrive2 Duo, Driver version 3.3.3 build 716 with Firmware v7.2.5 formatted as NVMFS.


There is clear difference to results obtained on DimitriK’s blog. First of all these results for both servers are significantly better. The system, I used has less cores but they are higher frequency. Additionally, this system has a more recent version of NVMFS. In my results, I used a 24 hour measure time and 150G database. DimitriK’s had 30 minutes in his blog post. Also, I used almost the same configuration, with one exception. I had exactly same amount of innodb_mtflush_threads as innodb_page_cleaners). In my results, MariaDB still offers better performance than MySQL. But, lets take a look at the page compressed results also.



Clearly, these new parameters are better than previously used parameters. I thank DimitriK for pointing out these.

Difference between MariaDB and MySQL is even bigger and still MariaDB offers better performance compared to MySQL. Bottom line is that I can’t repeat the results in the blog. This version of MariaDB indeed does not contain the fix for InnoDB index lock contention, but that does not seem to be the problem in this environment. Looking into performance schema numbers, it can be seen.

Just for a record, here is the used configuration variables.


My observations:

  • Configuration variable values can affect significantly to performance and thus it is important to tune the variables based on benchmark and hardware to get best possible performance.
  • Performance measurements on my original blog are correct if not optimal.
  • I could not repeat the significant difference on performance presented on DimitriK’s blog. Some possible reasons:
    • We have different distributions and hardware
    • Blog used short 30min measure time (I do not think this is the issue)
    • Blog used only uncompressed tables (based on my results, this is not the issue)
    • Blog used XtraDB on MariaDB (as it is default), this could have some effect but not all
    • I used default compilation (cmake . ; make )
  • MariaDB performance is not optimal because of the index lock contention pointed out by DimitriK. This will be fixed on later versions of MariaDB 10.1.