What's New in MariaDB 10.4

MariaDB 10.4 is a current development branch of MariaDB. Recently, on the 21st of May, the third Release Candidate (10.4.5) was released, bringing us closer to the official release. That’s why we thought it might be a good idea to take a look at the new 10.4 features. We will also share some thoughts on a recent blog post published by MariaDB Corporation. For information about the release itself, you can find all the details in the changelog of MariaDB 10.4.0.

Performance Changes

Unicode character sets are typically slower than charsets like latin1, mostly due to their size. MySQL 8.0 brought significant improvements in this area, and MariaDB 10.4 should also be noticeably faster than 10.3 in this regard. It is quite an important improvement – people really love to use emojis, which require UTF8 to be enabled. Some work has been done in the optimizer – MariaDB 10.4 should work better for IN() subqueries as it is now possible to push conditions into materialized subqueries.

Starting and stopping InnoDB can take a while, depending on the amount of data in redo logs. MariaDB 10.4 will improve startup, shutdown and purging. Such improvements are especially important given the popularity of hot backup tools like mariabackup and xtrabackup. Those tools, in the end, go through the InnoDB startup process from an unclean shutdown when they apply redo logs, therefore every improvement in that area should reduce the time needed to restore backups.

InnoDB Changes

MariaDB 10.4 has received an instant DROP COLUMN operation. It is now also possible to reorder the columns in the table without a need of rebuilding it. We can’t stress how important this is. You may wonder what are the most common operations that you do in the production environment? We would say it is adding or removing an index. Another most common operation would be operations on the columns – add a new column and remove existing column. So far the most common approach was to use external tools to do the job: pt-online-schema-change or, more recently, gh-ost. Both have their limitations (gh-ost doesn’t work for Galera Cluster, for example) which may make it impossible to use them on your system. Especially tricky are foreign keys. With instant DROP COLUMN (instant ADD COLUMN is already available), a big part of the schema changes can be performed ad hoc, without detailed scheduling and planning, as it has to be done now. It’s important to keep in mind that instant changes are what we want to have. There are non-blocking schema changes, like creating an index, but such operations pose serious challenge when the replication is used as they induce replication lag. Thus, even though the operation could have been executed on live system, we prefer to use workarounds like pt-online-schema-change to keep better control over the process.

This is not the only improvement in how schema changes are executed. MariaDB 10.4 will benefit from faster extension of VARCHAR columns, additionally character set and collation changes on non-indexed columns will be instant.

General Changes

One of the biggest changes are changes in the user management. Mysql.host table will not be created, mysql.user table is deprecated. User accounts and global privileges will be kept in the mysql.global_priv table. This is potentially a serious change for all the tools (including ClusterControl), which have an option to manage MySQL and MariaDB users – new cases will have to be written to cover user management in MariaDB 10.4 and onwards. While we acknowledge that changes are needed, this definitely does not help to maintain tools for both MariaDB and MySQL, making the tooling landscape even more divided than it already is. Talking about users, MariaDB 10.4 comes with an option for expiring user password. This is definitely a step in a good direction – it helps to enforce good practices regarding password management.

Even though we will cover it in a separate blog in more detail, we have to mention here support for Galera 26.4 – MariaDB 10.4 will benefit from a new Galera version with features like streaming replication or improved SST thanks to backup locks.

Finally, in MariaDB 10.4 you can set sql_mode=MSSQL. This is an initial implementation but sql_mode=ORACLE was also an initial implementation at some point. This shows MariaDB’s focus on enterprise customers – if Oracle customers decide to migrate, it is quite likely that MariaDB adoption among Microsoft SQL Server will also grow as more features will be added and migration will become less of an issue.

MariaDB Being a Fork

Quite recently we saw a blog post explaining MariaDB stance on InnoDB changes and compatibility. The gist is that MariaDB will no longer merge InnoDB features from MySQL, the focus will be on the stability and performance improvement done by MariaDB. This basically means that MariaDB will become incompatible with MySQL. Even if you could do the binary upgrade in the past, this will not be possible in the future. Even right now it can be tricky to execute. This increases the importance of tools like mydumper/myloader as logical backup will be the only way for migration. What is good, MariaDB will be able to own the stability of their fork of InnoDB – they will not have to deal with issues introduced by upstream developers therefore we can expect less bugs being introduced.

Performance-wise we have to wait for benchmarks but given the historical data, we can assume MariaDB will be slower than MySQL. In the past benchmarks what we typically see is that the performance increase for MariaDB kicks in when more recent InnoDB version has been integrated. This will no longer be the case which makes us wonder how MariaDB will fare in the performance comparison from now on and if the improvements introduced by MariaDB will be enough to keep up with MySQL 8.0 and further versions.

For us users, all of this means that MariaDB 10.4 should be more stable than the previous releases. It also means that eventually we will have to learn internals of two different storage engines – especially if we care about the performance. This is far from ideal but that’s the way it is. Tools will have to be designed to work with one or the other version of InnoDB (or additional work will have to be added to support both MySQL and MariaDB). We will keep an eye on how this will progress. When you think of it, it is not such a surprising move – MariaDB always had to take its time to integrate with more recent InnoDB version. With more and more incompatible features being added to MariaDB and huge changes introduced in MySQL 8.0, it makes sense to focus on developing new functionality rather than on porting incompatible InnoDB from upstream MySQL.

We hope this short blog post gave you insight into changes that will hit the production systems when going to MariaDB 10.4.