MariaDB vs. MySQL: faz diferença para o seu site?

Cerca de 60% dos sites WordPress no gráfico de versões de banco de dados do WordPress.org rodam MariaDB, e cerca de 40% rodam MySQL. O WordPress aceita qualquer um dos dois: MariaDB 10.11 ou posterior, ou MySQL 8.0 ou posterior. Você provavelmente não vai perceber o mecanismo por trás do seu site até ele ir para uma hospedagem que roda o outro.

Uma migração assim pode travar por causa de uma única linha de erro. Uma pessoa que exportava do MySQL 8.0 para o MariaDB recebia Unknown collation utf8mb4_0900_ai_ci em todas as tentativas, e a pergunta dela no Stack Exchange tem 74.574 visualizações. No nosso servidor de teste (que não é um servidor da DreamHost), a migração inversa falhou da mesma forma. Uma tabela criada com a collation padrão do MariaDB 11.8 interrompeu uma importação no MySQL 8.4 com Unknown collation: 'utf8mb4_uca1400_ai_ci', enquanto um banco de dados WordPress migrou sem problemas nas duas direções.

Qual mecanismo cada plano da DreamHost usa

Todos os planos da DreamHost em que nós gerenciamos o banco de dados para você usam MySQL. A tabela de versões da Central de Ajuda da DreamHost lista 8.0 para o MySQL compartilhado e 8.0 ou 8.4 para servidores dedicados, dependendo da versão do Ubuntu. A página do MySQL VPS lista o MySQL 8.0. A consulta abaixo mostra o que o seu roda.

A VPS gerenciada mantém seus bancos de dados nos servidores MySQL compartilhados da DreamHost, então segue a linha da hospedagem compartilhada. No plano de servidor dedicado, você também pode instalar a versão do MySQL que quiser, de acordo com a visão geral do MySQL da Central de Ajuda da DreamHost.

Na hospedagem compartilhada, se seu app precisa do MySQL 8.4 antes de o seu servidor migrar, a resposta da Central de Ajuda é adicionar um MySQL VPS e mover seus bancos de dados para ele. Antes de adicionar um, veja se o seu banco de dados está deixando seu site lento e, se você também está cotando um banco de dados na nuvem, compare os preços do RDS for MySQL com os de um servidor MySQL privado.

Como verificar o seu

1. Abra o phpMyAdmin
   Faça login no phpMyAdmin pelo seu panel da DreamHost ou pelas ferramentas do seu próprio servidor.
2. Clique na aba SQL
   Isso abre uma caixa em que você pode digitar uma consulta para o servidor.
3. Execute a consulta de versão

   Cole isto e execute:

   sqlCopiar

   SELECT VERSION();

   Um servidor MySQL responde com um número simples, como 8.4.11. Um servidor MariaDB se identifica na resposta, e o nosso retornou 11.8.9-MariaDB-ubu2404.

Em uma VPS que você mesmo configura, a versão do Linux decide o que o apt install instala. O Ubuntu 24.04 traz o MySQL 8.0 e o MariaDB 10.11. O Ubuntu 26.04 traz o MySQL 8.4 e o MariaDB 11.8. O Debian 13 tem o MariaDB 11.8 e nenhum pacote de servidor MySQL, e o pacote default-mysql-server dele instala o MariaDB. Nosso teste confirmou isso e mostrou que o default-mysql-server do Ubuntu vai no sentido contrário: ele instala o MySQL, 8.4 no 26.04 e 8.0 no 24.04. Na nossa LAMP Stack VPS, a mesma consulta mostra qual versão do MariaDB você recebeu. Se você ainda não escolheu o Linux, nosso guia sobre qual Linux usar na sua VPS compara as quatro opções que oferecemos.

O que muda entre o MySQL 8.4 e o MariaDB 11.8

O MariaDB é feito pelos desenvolvedores originais do MySQL. Os dois foram se distanciando, e a lista de diferenças do próprio MariaDB é longa. Estas são as diferenças que o dono de um site pode encontrar.

Provavelmente você vai esbarrar primeiro na linha da collation. O MySQL 8 marca novas colunas de texto com utf8mb4_0900_ai_ci, e o MariaDB 11.4 e posteriores usam utf8mb4_uca1400_ai_ci, segundo a matriz de compatibilidade do MariaDB. Uma exportação leva esses nomes em cada linha CREATE TABLE. A lista de diferenças do MariaDB diz que o 11.8 conhece 550 collations, incluindo 44 aliases adicionados no 11.4.5 para facilitar a replicação a partir do MySQL. No nosso teste, o MariaDB 11.8 aceitou sem reclamar uma tabela do MySQL 8.4 marcada com utf8mb4_0900_ai_ci. O inverso falhou, porque o MySQL 8.4 não conhece utf8mb4_uca1400_ai_ci, e a importação parou com ERROR 1273. O WordPress não esbarra em nenhum dos dois problemas: ele criou todas as tabelas como utf8mb4_unicode_520_ci nos dois mecanismos.

As configurações padrão importam se você mesmo for comparar os dois. O MySQL 8.4 já vem com o log binário ativado, e o MariaDB deixa o log binário dele desativado. O Performance Schema segue a mesma divisão: ativado no MySQL, desativado no MariaDB 11.8. Um teste lado a lado que não mexe em nenhum dos dois compara tanto dois arquivos de configuração quanto dois mecanismos, por isso rodamos o nosso das duas formas.

Memória, velocidade e disco no nosso servidor de teste

Sem nenhuma conexão, o MySQL ficou em 427 MiB de memória e o MariaDB em 137 MiB. Rodamos as imagens oficiais do MySQL 8.4.11 e do MariaDB 11.8.9, uma de cada vez, em uma VM de teste com 2 vCPUs e 4 GB de memória, o mesmo tamanho do nosso plano Stack 4.

Em velocidade, os dois ficaram praticamente empatados depois que as configurações foram equiparadas. Cada mecanismo rodou o benchmark uma vez por configuração, poucas execuções para afirmar que um deles é mais rápido.

Você sentiria a diferença de memória em um servidor pequeno, onde o banco de dados divide a RAM com o PHP e o servidor web. Dos 3.904 MB da nossa VM de teste, 3.465 MB continuavam disponíveis com o MariaDB em repouso e 3.136 MB com o MySQL. Logo após o benchmark, desativar os dois extras padrão do MySQL reduziu a diferença dele em relação ao MariaDB de 356 MiB para 101 MiB. Para dimensionar um servidor de banco de dados, veja quanta RAM o MySQL precisa.

Seu aplicativo se importa?

Instalamos o WordPress 7.1.3 em cada mecanismo, geramos 200 posts e 500 comentários e carregamos a página inicial sem erros em nenhum dos dois. Os apps da tabela abaixo funcionam assim: confira a página de requisitos do seu app antes de pensar no mecanismo e, normalmente, você vai encontrar os dois listados com uma versão mínima. Os dados vêm da página de cada app, consultada em 16 de outubro de 2026.

O Ghost é o único app aqui que faz questão. A página de bancos de dados compatíveis dele diz que o MySQL 8 é o único banco de dados com suporte em produção e recomenda fortemente sair do MariaDB se você estiver usando.

Vale a pena olhar o Nextcloud 35 com atenção também. Os requisitos dele listam o MySQL 8.4 e o 9.7 e deixam o 8.0 de fora. Em um servidor que você mesmo gerencia, use o MySQL 8.4 ou uma das versões do MariaDB listadas.

Como mover um banco de dados entre eles

Para mover um banco de dados entre o MySQL e o MariaDB, em qualquer direção, você o exporta para um arquivo SQL e importa esse arquivo. O guia de migração do MariaDB responde à pergunta Can I perform an in-place upgrade? com um simples No para quem vem do MySQL 8.0 ou 8.4. Não dá para simplesmente copiar os arquivos.

1. Verifique a versão nos dois servidores
   Execute SELECT VERSION(); no servidor antigo e no novo. Saber de qual mecanismo você está saindo indica quais nomes de collation procurar no passo 3.
2. Exporte com a ferramenta do próprio servidor antigo

   No MySQL, use o mysqldump do próprio MySQL. O guia de migração do MariaDB pede isso, já que o mariadb-dump do MariaDB não foi muito testado com o MySQL. No MariaDB, use mariadb-dump. Indique um único banco de dados e omita --databases, para que o arquivo não tenha uma linha CREATE DATABASE:

   bashCopiar

   mysqldump --user=USER \
     --password \
     --single-transaction \
     --routines --triggers \
     --hex-blob \
     DBNAME > site.sql

   O artigo sobre erros de importação da DreamHost explica que uma linha CREATE DATABASE faz a importação falhar com ERROR 1044. Se você está migrando para o DreamPress, omita --routines e --triggers, porque os servidores MySQL do DreamPress não oferecem suporte a rotinas armazenadas nem triggers.

3. Troque os nomes de collation que o novo servidor não reconhece
   Um banco de dados WordPress normalmente pula este passo, já que o WordPress usou utf8mb4_unicode_520_ci nos dois mecanismos no nosso teste e migrou nas duas direções sem erros. Tabelas com a collation padrão do servidor podem falhar em uma direção. O MySQL 8.4 parou em Unknown collation: 'utf8mb4_uca1400_ai_ci' numa exportação do MariaDB 11.8, enquanto o MariaDB 11.8 aceitou o utf8mb4_0900_ai_ci do MySQL. Versões mais antigas do MariaDB rejeitam esse nome, como na pergunta do Stack Exchange. Substitua o nome desconhecido em todo o arquivo por utf8mb4_unicode_520_ci, que os dois mecanismos conhecem, e importe de novo. Essa é a correção usada nas respostas mais votadas do Stack Exchange, e é a collation que o WordPress escolheu nos dois mecanismos no nosso teste.
4. Importe para um banco de dados vazio
   Primeiro, crie o banco de dados e o usuário dele no seu panel e depois importe o arquivo no phpMyAdmin ou com o cliente mysql. No nosso teste, os dumps do mysqldump e do mariadb-dump definiram o próprio conjunto de caracteres. Se você enviar via pipe um arquivo SQL escrito à mão para o cliente mysql dentro da imagem Docker oficial do MySQL, adicione --default-character-set=utf8mb4: sem isso, esse cliente voltou para latin1 no nosso teste e corrompeu as letras acentuadas.
5. Teste o site antes de mudar o DNS
   Carregue algumas páginas, faça login no painel de administração, faça uma busca e salve um post.

Qual escolher

Para um site PHP, nossa escolha é o mecanismo que sua hospedagem já usa, mantido em uma versão com suporte.

Se você usa o MySQL 8.0, seu próximo passo é o MySQL 8.4, e você pode continuar no MySQL para chegar lá. A Oracle passou o MySQL 8.0 para o Sustaining Support em 21 de abril de 2026 e orienta os usuários a atualizar para o 8.4 ou o 9.7. A Central de Ajuda da DreamHost informa que os servidores dedicados já estão migrando para o 8.4, que os servidores compartilhados migram no cronograma da própria DreamHost e que clientes do MySQL VPS podem entrar em contato com o suporte para solicitar a atualização.

Como medimos

Fizemos o teste em 19 de outubro de 2026, em uma VM no Colima em um Mac com Apple M2: arm64, 2 vCPUs, 3.904 MB de memória visível, sem swap, Ubuntu 24.04.4 e Docker 29.5.2. Não usamos um servidor da DreamHost. Usamos as imagens oficiais mysql:8.4.11 e mariadb:11.8.9, fixadas por digest, e não alteramos nada nas execuções com a configuração de fábrica. A memória em repouso é a mediana de 12 leituras do docker stats, feitas com 5 segundos de intervalo após 2 minutos de estabilização, e o valor não tinha mudado 10 minutos depois. O benchmark foi o teste oltp_read_write do sysbench 1.0.20, com 4 tabelas de 100.000 linhas, que cabem no buffer pool padrão de 128 MB de cada mecanismo, 4 threads, 60 segundos de aquecimento e uma única execução de 120 segundos por mecanismo e configuração.

Nossos servidores VPS e dedicados usam processadores AMD EPYC, então compare os mecanismos pela proporção e não espere os mesmos números absolutos neles. Não testamos um MySQL VPS, o MySQL compartilhado nem nossa imagem LAMP Stack. Cada benchmark rodou uma única vez, com dados sintéticos mais simples que o tráfego de um site real. A execução do MariaDB também registrou 683 erros que o sysbench tenta novamente e contabiliza à parte (cerca de 6 por segundo), e a do MySQL não registrou nenhum; não investigamos o motivo. A verificação do WordPress abrangeu a instalação, o conteúdo gerado e o carregamento das páginas, e cada migração usou a ferramenta de dump do próprio mecanismo de origem.

Perguntas frequentes sobre MySQL e MariaDB