There has been a lot of discussion about MariaDB 10.0 throughout the whole year. When will it be released, what will it include, what is the focus on MariaDB going forward, etc? My feeling is that people have in the past few months started to understand the value of MariaDB 10.0. There is a good group of people and companies that have been trying out and using the MariaDB 10.0 alpha releases and providing us with excellent feedback.

MariaDB 10.0 is a massive release with loads of new features which ease several pain points that MariaDB and MySQL users have run into over the years.

The highlights of MariaDB 10.0 can be divided into the following areas:

  • Replication enhancements
  • Storage engines
  • Optimizer enhancements
  • Administration improvements
  • Other important new features
  • Merged features and functionality from MySQL 5.6

I’ll go through each of these areas briefly to give an overview on what they include.


Global Transaction Id – In replication, MariaDB 10.0 introduces a new building block, Global Transaction Id(GTID). The implementation is different from the corresponding functionality in MySQL 5.6 and the main goals of the implementation have been 1) make it easy to set up replication with GTID and easily provision new slaves and 2) support other replication features such as Multi-Source Replication (see below). The introduction of GTID also makes the slaves crash safe, which they haven’t been before.

Multi-Source Replication – With Multi-source replication, contributed by Lixun Peng and Taobao you can replicate data from many masters to one slave. This is very useful when you have sharded your data and want a complete copy of it on one server. For this very reason Tumblr, the microblogging site, nowadays part of Yahoo! is already using this feature. Check out the story.

Parallel Slave (sponsored by Google) – Finally, MariaDB 10.0 solves a long lasting replication challenge that even exists in MySQL 5.6. Until now, with enough writes (INSERT/UPDATE) happening on a master the slaves would not be able to keep up at the same pace and they would lag behind. With the parallel slave feature in 10.0 this challenge is now gone. The slaves will adapt to the speed of the master and apply binlog events in parallel. Transactions will be applied in parallel if they were executed in parallel on the master. Unlike MySQL 5.6, the transactions can concern the same database or even the same table.


Many storage engine developers have been actively engaging with the developers of MariaDB lately and as a result there are several new storage engines in MariaDB 10.0 (in alphabetical order):

  • Cassandra Storage Engine: Combine data from Cassandra with your data in MariaDB, read and write Cassandra data, and connect many MariaDB servers to one Cassandra ring, creating a high-availability cluster.
  • Connect Storage Engine: Use Connect to handle data in files or behind ODBC as if that data was part of the data stored in MariaDB. Developed and contributed by Olivier Bertrand.
  • Sequence Storage Engine: Create numerical sequences that are stored in memory and can be used in your queries. For some use case examples check this article.
  • Spider Storage Engine: A storage engine with built in sharding capabilities. Developed and contributed by Kentoku Shiba.
  • TokuDB: A storage engine designed for high performance write-intensive workloads. Developed and contributed by Tokutek.


Engine Independent Persistent Statistics – Statistics are now provided separately from storage engines. Before, statistics were supplied by the storage engines themselves and the quality of the statistics were usually quite poor. Also the storage engine interface puts a lot of restrictions on them. Statistics are used by the query optimizer to choose the best execution plan for each SQL statement. Better statistics results in better execution plans and end users will experience faster results in general.

Histograms – To improve query optimization, MariaDB 10.0 introduces histograms. Histograms can be collected for both indexed and non indexed columns. Histogram data allows the query optimizer to make better query plan choices for complex multi-table queries.

Optimizations for EXISTS subqueries – the optimizer will convert EXISTS subqueries to IN, when possible. This conversion allows the usage of semi-join optimizations or Materialization optimization for certain classes of EXISTS subqueries.


10.0 includes a set of features that make the life of DBAs easier:

  • Roles – This is a big thing! Long awaited roles are introduced in MariaDB. DBAs can now create roles with certain permissions and assign users to the roles. Thanks to Google Summer of Code and developer Vicențiu Ciorbaru!
  • SHOW EXPLAIN – get the query plan of a running statement.
  • EXPLAIN in the Slow Query Log – write EXPLAIN output into the slow query log.
  • EXPLAIN INSERT/UPDATE/DELETE – EXPLAIN for INSERT/UPDATE/DELETE has been added in the same way as in MySQL 5.6, but the implementation is different.
  • SHOW PLUGIN SONAME – list all plugins despite them being installed or not.
  • SHUTDOWN – Finally use SQL to SHUTDOWN the server
  • KILL QUERY ID – Kill a specific query with its id, not the thread id (solves a nasty race condition).
  • Per-connection memory usage – List each connection with amount of memory used


There are also a bunch of new interesting features that don’t fall into the above categories:

New REGEXP – The switch to the modern regexp library PCRE together with the new SQL
functions REGEXP_REPLACE, REGEXP_SUBSTR, REGEXP_INSTR improve MariaDB text processing capabilities drastically. Developed during Google Summer of Code by Sudheera Palihakkara.

DELETE … RETURNING – Many users asked for the possibility for the DELETE statement to return the deleted rows in a resultset. It’s now possible by adding RETURNING at the end of the statement.

ALTER … IF [NOT] EXISTS – In your ALTER statements you can now add the IF or IF NOT keywords to e.g. add a column or create an index if it does or does not exist from before.

Named Dynamic Columns – In earlier versions of MariaDB Dynamic Columns, which allows for a different number of columns in each row, columns could only be referred to by number. Now the columns can be referred to by name.

Multiple GET_LOCK() – The use of many user level locks is now supported. Developed and contributed by Konstantin Osipov.


Selected pieces of MySQL 5.6 have been merged into MariaDB 10.0. The main ones are:

  • InnoDB – Most InnoDB enhancements are now in MariaDB 10.0.
  • Performance Schema – The full new performance schema with all the new event filtering, instrumentation, and other goodies.
  • Online ALTER – Do many of your schema changes without interrupting the system
  • Filesort optimization for queries using the ORDER BY … LIMIT optimization – A useful optimization for showing only a few rows of a bigger result set.
  • Character set extensions
  • TO_BASE64(), FROM_BASE64

Obviously there exist many smaller enhancements in MariaDB 10.0 and other things merged from 5.6, but the above overview of new features and merges includes the biggest ones.

As you can see, the community has been very active in contributing to 10.0 and it’s absolutely fantastic to be able to have all these new features pulled together into MariaDB and having them available to all MariaDB 10.0 users by default. A big thank you to all contributors!

Go give it a try and download the MariaDB 10.0.5 Beta!

Download MariaDB 10.0.5

Release Notes Changelog What is MariaDB 10.0?

If you’re excited about MariaDB 10.0 and its features or MariaDB in general and have a great MariaDB story to share, about some interesting use of MariaDB or some specific feature you love, please let us know.

PS. If you are attending Percona Live in London make sure you come and celebrate the launch of the MariaDB 10.0 beta with us over a drink or two on Mon 11th Nov. More info here.


First, congratulations Oracle on the GA of MySQL 5.6! Well done!

In this post I walkthrough the features of the first two alpha versions of MariaDB 10.0. The first, 10.0.0-alpha, which was made available in November, and 10.0.1-alpha that saw daylight yesterday. I will go through the features by placing them in the following categories:

  • MariaDB 10.0-only Features (features that aren’t in MySQL 5.6)
  • MariaDB 10.0 Merged Features (features merged from MySQL 5.6)
  • MariaDB 10.0 Reimplemented Features (features reimplemented from features in MySQL 5.6)
  • MariaDB 5.x Features now in MySQL 5.6 (features introduced in earlier MariaDB versions which have now been introduced in MySQL 5.6)
  • MariaDB 5.x Features Backported from MySQL 5.6 (features introduced in earlier MariaDB versions which were backports of features from MySQL 5.6 development versions)

Some of the features will have links to the MySQL manual for the documentation Oracle has made available on the feature.

MariaDB 10.0-only Features

Features in this section are unique to MariaDB 10.0 and aren’t found in MySQL 5.6.

Available since 10.0.0
  • Multi-source replication (MDEV-253)
    • Multi-source replication is a longtime wish of many users. In scenarios where you partition your data over many masters you can then replicate the data from all masters onto one slave. Typical use cases are:
      • Data partitioned over many masters can be pulled together onto one slave for analytical queries
      • Many masters can replicate to the same slave and a complete backup can be done on the slave
      • Newer hardware usually provides more performance. Usually all hardware isn’t upgraded at once and multi-source can be used for replicating many masters to a powerful new slave.
    • Original code from Taobao
  • Even faster Group Commit
    • Further enhancements have been made to group commit. A couple of blog posts about the improvements by the developer, Kristian Nielsen, can be found here.
    • Get the query plan of a running statement.
Now available in 10.0.1
  • Cassandra Storage Engine
    • An integration of the NoSQL database Apache Cassandra. Cassandra is seen as a storage engine to MariaDB. The integration enables:
      • Combining data from Cassandra and MariaDB
      • Reading and writing to Cassandra from MariaDB. SQL’s SELECT, INSERT, UPDATE and DELETE all work.
  • Engine independent statistics
    • Optimizer statistics is the collection of data that describe more details about the database and the objects in the database.
    • Statistics are now provided separately from storage engines. Before, statistics were supplied by the storage engines themselves and the quality of the statistics were usually quite poor. Also, since before this they were provided through the storage engine interface, a lot of restrictions were put on them.
    • These statistics are used by the query optimizer to choose the best execution plan for each SQL statement. Better statistics results in better execution plans and end users will experience faster results in general.
    • Statistics are collected also for non-indexed columns. InnoDB’s statistics, for example, were previously only for indexes.
  • Improved Dynamic Columns
    • Dynamic Columns has been in MariaDB for a while already. This feature allows you to store a different set of columns for every row in a table. In that manner Dynamic Columns can be called NoSQL-like.
    • Since MariaDB introduced Dynamic Columns there has been user feedback and research going on to improve it further. Dynamic Columns has some new capabilities that now are in mainline MariaDB:
      • Database interoperability: It’s pretty rare that companies use only a single type of database and even critical business systems are often built on several different types of databases. Usually the data from those different databases is combined in an upper application level. MariaDB introduces the possibility of doing this at a low level inside the MariaDB database. The first implementation of this is integration with Cassandra. With Dynamic Columns and the Cassandra Storage Engine you can now combine data residing in Cassandra with data inside MariaDB and this is done through normal looking queries on the MariaDB side.
      • Data interchange: JSON has become a very popular standard for data interchange. In Dynamic Columns one can now request a row in JSON format.
  • Per thread memory usage (MDEV-4011)
    • Based on a patch by Taobao, INFORMATION_SCHEMA and SHOW STATUS enables the analysis of thread specific memory usage
  • Faster ALTER TABLE with UNIQUE key (MDEV-539)
    • Significant speed up of ALTER TABLE with unique keys (for Aria and MyISAM storage engines)

MariaDB 10.0 Merged Features

Features listed in this category have been directly merged from MySQL 5.6.

Already available since MariaDB 10.0.0
  • InnoDB and Performance Schema
    • Most InnoDB enhancements, but some, for example InnoDB’s fulltext capabilities, will come in an upcoming version of 10.0.
      MySQL Manual: InnoDB.
    • The full new performance schema with all the new event filtering, instrumentation, and other goodies.
      MySQL Manual: Performance Schema
  • ORDER BY … LIMIT -optimization
    • A useful optimization for showing only a few rows of a bigger resultset.
      MySQL Manual:Limit Optimization
Now added in 10.0.1
  • Plugin-load-add (MDEV-3860)
    • Used to avoid specifying a large set of plugins in a single long argument

MariaDB 10.0 Reimplemented Features

These features are re-implementations of the corresponding functionality in MySQL 5.6. In future versions of MariaDB 10.0 there will be a few more features in this category. I’ll cover them in a future blog post.

In 10.0.1
  • Add full support for auto-initialized/updated timestamp and datetime

MariaDB 5.x Features now in MySQL 5.6

Earlier MariaDB 5.x versions included features that have now been introduced in MySQL 5.6. It should be noted that the corresponding features in MySQL 5.6 haven’t been merged from MariaDB. Oracle has re-implemented them.

MariaDB 5.x Features Backported from MySQL 5.6

These features were merged from MySQL 5.6’s development trees to MariaDB, where they were then hardened for production use.

  • Binlog checksums, were introduced in MariaDB 5.3. It is backport of the corresponding feature in MySQL 5.6.

As you can see above there are quite many features in MariaDB 10.0 already, but more is coming. Stay tuned for an update on features going into MariaDB 10.0.2.

In May of last year I blogged about MariaDB 10.0 for the first time. We received some feedback, digested it, and I further explained MariaDB 10.0. Now, with the first Alpha of MariaDB 10.0 out and a new year just beginning, now is a good time to explain a little bit more, especially about MariaDB 10.0 and MySQL 5.6 as I and others in the MariaDB project get asked a lot about the differences between them.

First, here are some details as to why we didn’t just take MySQL 5.6 as a base and create something that would have been called MariaDB 5.6. These details haven’t been widely shared before:

  1. The file structure of the codebase in MySQL 5.6 has changed. Single code files have been split into several and code has been moved around from one file to another. To merge MariaDB with this new file structure would be a very time consuming job. Why the file structure changed on the MySQL side is something that I don’t know the answer to.
  2. MariaDB 5.5 contains a large amount of code differences from MySQL 5.5 and includes many features that are only now being introduced in MySQL 5.6. In these cases the MySQL and MariaDB versions of the same functionality are compared and both design and QA reviews are done. Obviously, the one that scores better will be in MariaDB. In most cases the decision has been to use the MariaDB version of the feature.
  3. All new code (at least bug fixes) in MySQL does not necessarily have a corresponding test case anymore. When you merge such functionality into other code which differs from the code where the functionality originally resided, test cases are extremely important for evaluating that the functionality works as expected.

Very much in line with the second and third argument above, Stewart Smith from Percona wrote yesterday about the latest security fix in MySQL introducing a regression and how the QA work done in the MariaDB project and the importance of test cases saved him from placing the regression in Percona Server.

MariaDB is not only about being an alternative to MySQL. MariaDB is largely about innovating and improving MySQL technology. MySQL 5.6 was not a suitable base for innovation, so the following happened:

  1. We needed to introduce a new version since we are already in the process of introducing new features like multi-source replication, Cassandra integration, engine independent statistics and many more. Whenever you introduce new features you typically advance to a new major version.
  2. It would have been wrong to call next version “MariaDB 5.6″, because it’s not based on MySQL 5.6. Instead we decided to jump to 10.0.
  3. We know MariaDB needs to implement many of the features introduced in MySQL 5.6 to be a viable alternative to MySQL 5.6 and we have taken a stepped approach in merging or recreating features from MySQL 5.6.

The first major version, MariaDB 10.0 will, for example, include the merged InnoDB, merged Performance Schema, and a new implementation of Global Transaction ID. MariaDB 10.0 is targeted to be GA in the summer.

Our goal with the stepped approach is to eventually have all features of MySQL 5.6 either merged or re-implemented. All re-implemented features will be made compatible with their MySQL versions. In the end, MariaDB 10 should be fully feature compatible with MySQL 5.6 and, of course, on top of that include many extra MariaDB-only features.

The decision to re-implement functionality is very simple. We re-implement if a given implementation in MySQL 5.6 lacks something from our or the users’ point of view. A decision to re-implement is not made in an “I would like to do this”-manner, nor is it influenced by a “not-invented-here” syndrome. Each case is truly evaluated and extensively discussed. You can participate in these discussions and get your voice heard by joining the mailing list at

Could another route have been chosen? Yes. We could have pulled in the latest version of MySQL 5.6 as a base for a version called MariaDB 5.6 and started patching. It should be kept in mind that MariaDB isn’t a bordered set of patches. Although MariaDB has MySQL as a basis there is a huge amount of engineering on top of it. The MariaDB engineers and QA are working full time on making MySQL technology better inside MariaDB.

There was also another possibility — to become a true fork, stop merging from MySQL, and break compatibility. But we didn’t want to take that path — we and MariaDB users in general do value much of the functionality introduced in MySQL and want it included in MariaDB.

MariaDB 5.5 has been a key part of MariaDB’s increasing popularity and we’re still riding upwards on that wave. More downloads every week, more distributions adopting MariaDB, and more big use cases.

Inside the MariaDB project we’re carefully handling a balancing act of being as easy an alternative to MySQL as possible while also introducing much-needed innovation, and keeping it all realistic as well. Without innovation MariaDB isn’t a product of its own.

Join the joint MariaDB & SkySQL roadshow to hear the latest about MariaDB and talk to us! Find the roadshow schedule and registration here.