Comparing Data At-Rest Encryption Features for MariaDB, MySQL and Percona Server for MySQL

Encryption at rest MariaDB MySQL Percona ServerProtecting the data stored in your database may have been at the top of your priorities recently, especially with the changes that were introduced earlier this year with GDPR.

There are a number of ways to protect this data, which until not so long ago would have meant either using an encrypted filesystem (e.g. LUKS), or encrypting the data before it is stored in the database (e.g. AES_ENCRYPT or other abstraction within the application). A few years ago, the options started to change, as Alexander Rubin discussed in MySQL Data at Rest Encryption, and now MariaDB®, MySQL®, and Percona Server for MySQL all support encryption at-rest. However, the options that you have—and, indeed, the variable names—vary depending upon which database version you are using.

In this blog post we will take a look at what constitutes the maximum level of at-rest encryption that can be achieved with each of the latest major GA releases from each provider. To allow a fair comparison across the three, we will focus on the file-based key management; keyring_file plugin for MySQL and Percona Server for MySQL along with file_key_management plugin for MariaDB.

MariaDB 10.3

The MariaDB team take the credit for leading the way with at-rest encryption, as most of their features have been present since the 10.1 release (most notably the beta release of 10.1.3 in March 2015). Google donated the tablespace encryption, and eperi donated per-table encryption and key identifier support.

The current feature set for MariaDB 10.3 comprises of the following variables:

Maximising at-rest encryption with MariaDB 10.3

Using the following configuration would give you maximum at-rest encryption with MariaDB 10.3:

This configuration would provide the following at-rest protection:

  • automatic and enforced InnoDB tablespace encryption
  • automatic encryption of existing tables that have not been marked with ENCRYPTED=NO
  • 4 parallel encryption threads
  • encryption of temporary files and tables
  • encryption of Aria tables
  • binary log encryption
  • an encrypted file that contains the main encryption key

You can read more about preparing the keys, as well as the other key management plugins in the Encryption Key Management docs.

There is an existing bug related to encrypt_tmp_files (MDEV-14884), which causes the use of mysqld --help --verbose to fail, which if you are using the official MariaDB Docker container for 10.3 will cause you to be unable to keep mysqld up and running. Messages similar to these would be visible in the Docker logs:

N.B. you should be aware of the limitations for the implementation, most notably log tables and files are not encrypted and may contain data along with any query text.

One of the key features supported by MariaDB that is not yet supported by the other providers is the automatic, parallel encryption of tables that will occur when simply enabling innodb_encrypt_tables . This avoids the need to mark the existing tables for encryption using ENCRYPTED=YES , although at the same time it also does not automatically add the comment and so you would not see this information. Instead, to check for encrypted InnoDB tables in MariaDB you should check information_schema.INNODB_TABLESPACES_ENCRYPTION , an example query being:

As can be inferred from this query, the system tables in MariaDB 10.3 are still predominantly MyISAM and as such cannot be encrypted.


Whilst the enterprise version of MySQL has support for a number of data at-rest encryption features as of 5.7, most of them are not available to the community edition. The latest major release of the community version sees the main feature set comprise of:

The enterprise edition adds the following extra support:

Maximising at-rest encryption with MySQL 8.0

Using the following configuration would give you maximum at-rest encryption with MySQL 8.0:

This configuration would provide the following at-rest protection:

  • optional InnoDB tablespace encryption
  • redo and undo log encryption

You would need to create new, or alter existing tables with the ENCRYPTION=Y option, which would then be visible by examining information_schema.INNODB_TABLESPACES , an example query being:

N.B. You are able to encrypt the tablespaces in 5.7, in which case you should use information_schema.INNODB_SYS_TABLESPACES as the internal system views on the data dictionary were renamed (InnoDB Changes).

Unfortunately, whilst all of the tables in the mysql schema use the InnoDB engine (except for the log tables), you cannot encrypt them and instead get the following error:

Interestingly, you are led to believe that you can indeed encrypt the general_log and slow_log tables, but this is in fact a bug (#91791).

Percona Server for MySQL

Last, but not least we have Percona Server for MySQL, which, whilst not completely matching MariaDB for features, is getting very close. As we shall see shortly, it does in fact have some interesting differences to both MySQL and MariaDB.

The current feature set for 5.7, which does indeed exceed the features provided by MySQL 5.7 and for the most part 8.0, is as follows:

N.B. It is important to review the documentation for each of these variables as some new features are marked as ALPHA or BETA at the time of writing. You should ensure that you have thoroughly tested the configuration in your environment before fully deploying across your production server. Since you can deploy the changes on a slave without changing the master, then you could choose to use one or more read-only slaves to test out in production, if that is possible in your environment.

Maximising at-rest encryption with Percona Server for MySQL 5.7

Using the following configuration would give you maximum at-rest encryption with Percona Server 5.7 for a new, bootstrapped instance:

N.B. For existing servers, the use of innodb_sys_tablespace_encrypt is not  possible at this time.

This configuration would provide the following at-rest protection:

  • automatic and enforced InnoDB tablespace encryption
  • encryption of the system tablespace, protecting the change buffer plus any undo logs or user data that reside in it
  • encryption of the parallel double-write buffer, ensuring that page writes for encrypted tables remain in an encrypted state before being flushed to disk
  • encryption of temporary files and tables
  • binary log encryption
  • encryption when performing online DDL

There are some additional features that are due for release in the near future:

  • Automatic key rotation
  • Undo log and redo log encryption
  • InnoDB tablespace and redo log scrubbing
  • Amazon KMS keyring plugin

Just like MySQL, encryption of any existing tables needs to be specified via ENCRYPTION=Y via an ALTER, however new tables are automatically encrypted. Another difference is that in order to check which tables are encrypted you can should the flag set against the tablespace in information_schema.INNODB_SYS_TABLESPACES, an example query being:

Here you will see something interesting! We are able to encrypt most of the system tables, including two that are of significance, as they can contain plain text passwords:

In addition to the above, Percona Server for MySQL also supports using the opensource HashiCorp Vault to host the keyring decryption information using the keyring_vault plugin; utilizing this setup (provided Vault is not on the same device as your mysql service, and is configured correctly) gains you an additional layer of security.

You may also be interested in my earlier blog post on using Vault with MySQL, showing you how to store your credentials in a central location and use them to access your database, including the setup and configuration of Vault with Let’s Encrypt certificates.


There are significant differences both in terms of features and indeed variable names, but all of them are able to provide encryption of the InnoDB tablespaces that will be containing your persistent, sensitive data. The temporary tablespaces, InnoDB logs and temporary files contain transient data, so whilst they should ideally be encrypted, only a small section of data would exist in them for a finite amount of time which is less of a risk, albeit a risk nonetheless.

Here are the highlights:

MariaDB 10.3MySQL 8.0Percona Server 5.7
encrypted InnoDB dataYYY
encrypted non-InnoDB dataAria-onlyNN
encrypted InnoDB logsYYPartial
automatic encryptionYNY
enforced encryptionYNY
automatic key rotationYNTBA
encrypted binary logsYNY
encrypted online DDL?NY
encrypted keyringYEnterprise-onlyN
Hashicorp VaultNNY
AWS KMSYEnterprise-onlyTBA


Extra reading:

You May Also Like

If your business has been contemplating a switch from MariaDB to MySQL (or vice versa), Percona’s white paper on choosing the best database for your needs is a must read. If you are considering making the move to MySQL, check out our white paper Why Choose MySQL? for an in-depth review.

Share this post

Comments (6)

  • Aurélien


    what is interest to crypt mysql.slave_master_info, if the file is not crypted ? Else it’s good point for mysql.servers and more if you use spider like me.

    August 31, 2018 at 8:19 am
    • Ceri Williams

      Hi Aurélien, when you use TABLE instead of FILE for master_info_repository then there is no file on disk, thus being able to encrypt the slave_master_info table means that you have encrypted the credentials.

      September 3, 2018 at 8:26 am
  • gihrig

    Hi Ceri,

    Great article, much appreciated!

    I’m wondering, in the case of Percona server 5.7, is there a performance penalty for encryption as you have outlined here?

    If so, can you provide any general guidelines as to how much of a penalty exists?

    March 15, 2019 at 11:06 pm
  • Ceri Williams March 18, 2019 at 7:50 am
  • gihrig

    Thank Ceri, most informative!

    March 18, 2019 at 3:20 pm
  • Marcos Albe

    One missing bit is audit log encryption in MySQL 8; I reckon the Audit plugin is enteprise, but having it encrypted is a nice feature. Slow log and error log too could be encrypted.

    March 21, 2019 at 8:08 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.