Checklist MariaDB vs MySQL: diferenças que impactam sua hospedagem

MariaDB e MySQL são gerenciadores de banco de dados relacionais com origem comum, mas que divergem de forma relevante em licenciamento, storage engines, autenticação padrão e compatibilidade a partir do MySQL 8.0. Em ambientes de hospedagem Linux, a escolha entre os dois afeta diretamente a compatibilidade de aplicações, o desempenho sob carga e o processo de migração entre servidores.

Pré-requisitos para aplicar este checklist

• Acesso SSH ao servidor ou acesso ao WHM e cPanel com permissão de root
• AlmaLinux 10, Rocky Linux 10, Debian 13 ou Ubuntu 25.04 como sistema operacional
• MariaDB 11.8+ ou MySQL 8.4 LTS instalado ou em fase de avaliação
• Backup atualizado de todos os bancos de dados antes de qualquer alteração
• Conhecimento básico de linha de comando Linux e sintaxe SQL
• Acesso ao arquivo de configuração principal /etc/mysql/mariadb.conf.d/50-server.cnf ou equivalente

Origem e licenciamento: o que diferencia MariaDB de MySQL na raiz

Entender a origem dos dois bancos é o ponto de partida antes de avaliar recursos técnicos. O MySQL foi criado em 1995 e adquirido pela Oracle em 2010, passando a operar sob licença dual: GPL v2 para uso open source e licença comercial para funcionalidades enterprise. O MariaDB nasceu em 2009 como fork direto do MySQL, criado por Michael "Monty" Widenius — o desenvolvedor original — após a aquisição pela Oracle, com o objetivo de manter um projeto genuinamente open source sob licença GPL v2.

Até o MySQL 5.7, MariaDB mantinha compatibilidade quase total de API e sintaxe SQL. Com o lançamento do MySQL 8.0 e, mais recentemente, do MySQL 8.4 LTS, a Oracle introduziu recursos proprietários como autenticação caching_sha2_password por padrão, tipo de dado JSON nativo otimizado e Group Replication, criando divergências que impactam a portabilidade de aplicações existentes.

O MariaDB, por sua vez, adotou versionamento próprio a partir da série 10.x e, atualmente na linha 11.x, introduziu recursos exclusivos como Sequences nativos, engine Aria para tabelas temporárias internas, Spider engine para sharding horizontal e ColumnStore para análise de grandes volumes de dados — sem equivalente direto no MySQL Community Edition.

Checklist de diferenças técnicas entre MariaDB e MySQL

Este checklist de diferenças entre MariaDB e MySQL cobre os pontos críticos que afetam hospedagem Linux, compatibilidade com frameworks PHP e comportamento em servidores de produção com múltiplos domínios.

Storage engines disponíveis

• MariaDB 11.8+: InnoDB, Aria (substituto do MyISAM com journaling crash-safe), MyISAM, ColumnStore, Spider, CONNECT, Sequence
• MySQL 8.4: InnoDB como foco principal, MyISAM para uso legado, NDB Cluster e MEMORY
• Impacto prático: o engine Aria é usado internamente pelo MariaDB para tabelas temporárias em queries com ORDER BY e GROUP BY complexos, o que pode resultar em menos I/O em disco em comparação ao MySQL sob as mesmas condições

Autenticação padrão e compatibilidade com drivers

• MySQL 8.0+: usa caching_sha2_password como plugin padrão — bibliotecas de cliente mais antigas, como PHP com extensão mysqli sem atualização ou conectores JDBC desatualizados, podem falhar ao conectar sem ajuste explícito
• MariaDB 11.x: usa mysql_native_password ou ed25519 como padrão — mais compatível com aplicações legadas, mas exige atenção adicional ao hardening de autenticação
• Ação recomendada: ao migrar do MySQL 8.0 para MariaDB, verifique o plugin de cada usuário com SELECT user, host, plugin FROM mysql.user; antes de alterar qualquer aplicação

Suporte a JSON: diferença relevante em APIs modernas

• MySQL 8.4: JSON como tipo de dado nativo com armazenamento binário otimizado, índice funcional em colunas JSON e funções como JSON_TABLE() para transformar JSON em linhas relacionais
• MariaDB 11.x: JSON como alias para LONGTEXT, com funções JSON compatíveis para uso básico — adequado para leitura e escrita simples de payloads, mas sem a otimização de armazenamento do MySQL 8.4
• Impacto prático: em APIs REST que armazenam payloads JSON ou catálogos de produtos com estrutura variável, o MySQL 8.4 tem vantagem de desempenho em queries que filtram atributos dentro de colunas JSON

Thread Pool: recurso gratuito no MariaDB, pago no MySQL

• MariaDB: Thread Pool nativo e gratuito via diretiva thread_handling = pool-of-threads — reduz o overhead de criação de threads em servidores com alto volume de conexões PHP curtas e simultâneas
• MySQL Community Edition: Thread Pool disponível apenas na versão Enterprise (pago); usa o modelo one-thread-per-connection por padrão
• Impacto em VPS com 2-4 GB de RAM: em servidores com muitas conexões PHP-FPM simultâneas, o thread pool do MariaDB pode reduzir o consumo de memória por conexão de forma mensurável

Replicação e GTID: cuidado em ambientes mistos

• MariaDB: Galera Cluster integrado nativamente para replicação multi-master síncrona; GTID com formato próprio diferente do MySQL
• MySQL 8.4: Group Replication nativo e MySQL InnoDB Cluster como solução de alta disponibilidade; GTID com formato incompatível com o do MariaDB
• Atenção: em ambiente com réplicas mistas (um master MySQL e um slave MariaDB ou vice-versa), desabilite GTID e utilize replicação baseada em posição de binlog até que todos os nós estejam no mesmo banco

Query Cache: removido no MySQL, disponível no MariaDB

• MySQL 8.0+: Query Cache foi removido completamente — a alternativa oficial é ProxySQL, cache de aplicação com Redis ou Memcached
• MariaDB 11.x: Query Cache ainda disponível (depreciado, mas funcional) via query_cache_type = 1 — em workloads de leitura com queries idênticas repetidas, pode ser habilitado como paliativo
• Para produção moderna, independentemente do banco, a recomendação é usar estratégias de cache em camada de aplicação em vez de depender do Query Cache do banco

MariaDB vs MySQL no cPanel e hospedagem compartilhada

No contexto de hospedagem gerenciada via cPanel, a distinção entre os dois bancos tem implicações diretas para administradores de servidor. O cPanel 110 e versões superiores adotaram MariaDB como padrão nas instalações novas, especialmente em distribuições como AlmaLinux 10 e Rocky Linux 10. O administrador pode selecionar a versão via WHM > Software > MySQL/MariaDB Upgrade.

A interface do phpMyAdmin no cPanel funciona de forma idêntica com ambos os bancos. O recurso de conexão remota ao MySQL via cPanel também funciona com MariaDB sem alterações no fluxo do usuário final, pois o protocolo de comunicação é compatível.

Para quem administra um VPS com painel open source ou configura o ambiente manualmente, a escolha deve levar em conta:

• WordPress e CMSs PHP populares: funcionam identicamente com MariaDB 11.8+ e MySQL 8.4 — não há diferença funcional para o usuário final
• Laravel, Symfony, CodeIgniter: compatíveis com ambos; verifique se o driver PDO usa charset=utf8mb4 para evitar problemas de encoding com caracteres especiais
• Aplicações legadas escritas para MySQL 5.x: MariaDB oferece melhor compatibilidade retroativa do que MySQL 8.4, que removeu comportamentos permissivos do MySQL 5.7
• Aplicações com JSON nativo, Group Replication ou funcionalidades Oracle exclusivas: MySQL 8.4 é a escolha mais segura

Como migrar do MySQL para MariaDB sem perder dados

A migração entre MySQL e MariaDB é viável para bancos que utilizam InnoDB ou MyISAM sem dependências de funcionalidades exclusivas do MySQL 8.0+. O processo segue um fluxo de exportação, reinstalação e importação.

Atenção: execute um backup completo antes de iniciar qualquer etapa. Nunca remova o MySQL sem confirmar que o dump foi gerado com sucesso e está íntegro.

1. Exporte todos os bancos com mysqldump enquanto o MySQL ainda está em funcionamento
2. Anote os storage engines usados em cada tabela com SHOW TABLE STATUS
3. Remova o MySQL respeitando o procedimento da sua distribuição Linux
4. Instale o MariaDB 11.8+ a partir do repositório oficial
5. Configure o arquivo /etc/mysql/mariadb.conf.d/50-server.cnf com os mesmos parâmetros principais
6. Importe o dump e verifique integridade com mysqlcheck

Exportando todos os bancos com mysqldump

mysqldump -u root -p \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --quote-names \
  > backup_mysql_completo.sql

-- Output esperado (sem erros):
-- MySQL dump 10.13  Distrib 8.4.x, for Linux (x86_64)
-- Host: localhost    Database:
-- Server version   8.4.x
(processo encerra sem mensagens de erro)

Instalando MariaDB 11.8+ no AlmaLinux 10

dnf module disable mysql -y
curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | \
  bash -s -- --mariadb-server-version="mariadb-11.8"
dnf install -y MariaDB-server MariaDB-client
systemctl enable --now mariadb
mysql_secure_installation

-- Output esperado:
Installed: MariaDB-server-11.8.x-1.el10.x86_64
Started: mariadb.service (Active: active (running))

Importando o dump no MariaDB

mysql -u root -p < backup_mysql_completo.sql

Após a importação, verifique a integridade de todas as tabelas:

mysqlcheck -u root -p --all-databases --auto-repair

-- Output esperado (sem erros):
nome_do_banco.tabela           OK
outro_banco.outra_tabela       OK
(nenhuma linha com "error", "crashed" ou "repaired")

Corrigindo autenticação após migração

Se a aplicação PHP apresentar erro de conexão após a migração, identifique o plugin de autenticação de cada usuário:

SELECT user, host, plugin FROM mysql.user WHERE user NOT IN ('root', 'mariadb.sys', 'mysql');

Para garantir compatibilidade máxima com drivers PHP e aplicações legadas:

ALTER USER 'app_user'@'localhost'
  IDENTIFIED VIA mysql_native_password
  USING PASSWORD('SenhaForte@2026');
FLUSH PRIVILEGES;

Parâmetros de tuning essenciais: MariaDB e MySQL em hospedagem Linux

O ajuste de parâmetros de configuração tem impacto mais significativo no desempenho do banco do que a escolha entre MariaDB e MySQL em workloads típicos de hospedagem. Os parâmetros a seguir se aplicam a ambos e são válidos para servidores com 2 a 8 GB de RAM.

Edite o arquivo de configuração principal do MariaDB (/etc/mysql/mariadb.conf.d/50-server.cnf) ou do MySQL (/etc/mysql/mysql.conf.d/mysqld.cnf):

[mysqld]
# Alocar 50-70% da RAM ao buffer pool do InnoDB
innodb_buffer_pool_size         = 1G

# Tamanho do log de transações (impacta velocidade de escrita)
innodb_log_file_size            = 256M

# Máximo de conexões simultâneas (ajustar conforme RAM disponível)
max_connections                 = 150

# Encerrar conexões ociosas após 5 minutos
wait_timeout                    = 300
interactive_timeout             = 300

# Cache de descritores de tabelas abertas
table_open_cache                = 2000

# EXCLUSIVO MariaDB: habilitar thread pool
thread_handling                 = pool-of-threads
thread_pool_size                = 4

Atenção: a diretiva thread_handling = pool-of-threads é exclusiva do MariaDB. Se aplicada ao MySQL Community Edition, causará falha na inicialização do serviço — remova-a do arquivo de configuração antes de usar no MySQL.

systemctl restart mariadb
# aguarde e verifique o status:
systemctl status mariadb

-- Output esperado:
mariadb.service - MariaDB 11.8 database server
     Active: active (running) since ...
(nenhuma linha com "failed" ou "error")

Problemas comuns e como resolver

Sintoma: aplicação PHP não conecta ao MariaDB após migração do MySQL 8.0

Causa: o MySQL 8.0 usava caching_sha2_password como plugin padrão. Usuários exportados no dump podem ter sido importados com esse plugin, que o MariaDB 11.x não trata da mesma forma, resultando em erro de autenticação no driver PHP.

Solução: execute SELECT user, plugin FROM mysql.user; para localizar usuários com caching_sha2_password. Recrie-os usando IDENTIFIED VIA mysql_native_password no MariaDB e reinicie o PHP-FPM após a alteração.

Sintoma: erro "Table X doesn't exist" após importar dump do MySQL 8.0

Causa: o MySQL 8.0 introduziu palavras reservadas adicionais como RANK, GROUPS e SYSTEM. Se nomes de tabelas ou colunas no dump não estiverem entre backticks, o parser do MariaDB pode recusar a importação ao encontrar essas palavras em posição inesperada.

Solução: verifique se o dump foi gerado com a opção --quote-names (padrão no mysqldump moderno) usando grep -i "CREATE TABLE" backup.sql | head -20. Se os nomes não estiverem entre backticks, regere o dump com essa opção explicitamente antes de importar.

Sintoma: MariaDB consome mais memória do que o esperado após upgrade via cPanel WHM

Causa: ao fazer upgrade de versão via WHM, configurações do arquivo /etc/my.cnf legado podem persistir com valores de innodb_buffer_pool_size incompatíveis com a nova versão ou com a RAM disponível no servidor.

Solução: identifique qual arquivo de configuração está sendo carregado com mysql --verbose --help 2>&1 | grep -A 1 "Default options". Revise cada arquivo listado e garanta que innodb_buffer_pool_size corresponde a no máximo 70% da RAM disponível.

Sintoma: replicação para após migrar master de MySQL para MariaDB

Causa: os formatos de GTID do MySQL e do MariaDB são incompatíveis binariamente. Uma réplica MySQL configurada para seguir um master MariaDB com GTID habilitado não consegue interpretar os eventos de replicação corretamente.

Solução: em ambiente de replicação misto durante a migração, defina gtid_strict_mode = OFF no MariaDB e use replicação baseada em posição de binlog via CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=... até que todos os nós estejam no mesmo banco e versão.

Perguntas frequentes sobre MariaDB vs MySQL

MariaDB é compatível com MySQL?

MariaDB nasceu como fork do MySQL e mantém alta compatibilidade com a API e sintaxe SQL do MySQL até a versão 5.7. A partir do MySQL 8.0, surgiram divergências em recursos como autenticação padrão (caching_sha2_password) e JSON nativo, então aplicações que dependem de funcionalidades exclusivas do MySQL 8.0+ podem precisar de ajustes ao migrar para MariaDB 11.x.

Qual é mais rápido: MariaDB ou MySQL?

A resposta depende do workload. MariaDB tende a ter vantagem em consultas de leitura intensiva e replicação, graças ao Aria storage engine e otimizações no query planner. MySQL 8.0+ se destaca em workloads com JSON nativo e operações de escrita concorrente com InnoDB aprimorado. Em hospedagem compartilhada e VPS de entrada, a diferença prática é pequena e o tuning de configuração impacta mais do que a escolha do banco.

Posso migrar do MySQL para MariaDB sem perder dados?

Sim, a migração é possível e geralmente direta para bancos que usam InnoDB ou MyISAM. O processo envolve exportar os dados com mysqldump, instalar o MariaDB, importar o dump e verificar a integridade. Bancos que usam recursos exclusivos do MySQL 8.0+ (como funções JSON avançadas ou autenticação caching_sha2_password) exigem revisão antes da migração.

cPanel usa MariaDB ou MySQL por padrão?

O cPanel suporta ambos, mas nas versões recentes (cPanel 110+) o padrão passou a ser MariaDB 10.6 ou superior, dependendo da distribuição Linux do servidor. O administrador do servidor pode escolher a versão durante a instalação do cPanel ou via WHM em Software > MySQL/MariaDB Upgrade.

Qual banco de dados escolher para WordPress em hospedagem Linux?

WordPress funciona perfeitamente com ambos. MariaDB é a escolha mais comum em hospedagem compartilhada e VPS Linux por ser padrão no cPanel e em distribuições como AlmaLinux e Rocky Linux. Para WordPress, o fator decisivo não é o banco em si, mas o tuning de innodb_buffer_pool_size, query_cache e conexões máximas, que se aplicam igualmente a MariaDB e MySQL.

Conclusão

O checklist de diferenças entre MariaDB e MySQL deixa claro que a escolha ideal depende do perfil da aplicação, não de uma preferência genérica. Para a maioria dos cenários de hospedagem Linux com WordPress, CMSs PHP e stacks LAMP tradicionais, MariaDB 11.8+ é a opção prática por estar presente por padrão no cPanel e nas principais distribuições como AlmaLinux 10 e Rocky Linux 10. Para aplicações modernas com uso intensivo de JSON nativo, Group Replication ou que já dependem de funcionalidades específicas do MySQL 8.4, manter o MySQL é o caminho mais seguro e sem necessidade de ajustes de compatibilidade.

• Verifique o plugin de autenticação antes de qualquer migração: incompatibilidades entre caching_sha2_password e drivers PHP são a causa mais comum de falhas de conexão imediatamente após trocar o banco
• Priorize o ajuste de innodb_buffer_pool_size em ambos os bancos: essa configuração tem impacto maior no desempenho do que a escolha entre MariaDB e MySQL para workloads típicos de hospedagem com múltiplos sites
• Teste sempre em staging antes de migrar em produção: valide stored procedures, funções JSON, configurações de replicação e compatibilidade de drivers com a versão alvo antes de aplicar em ambiente com tráfego real

Leia também

• Solucionar lentidão no MySQL 8.0 antes que derrube sua aplicação
• Configurar MariaDB 11.4 no AlmaLinux 9: do padrão ao máximo
• Guia: Laravel não conecta ao MySQL no Debian 12

Precisa de ajuda com banco de dados na sua hospedagem?

Configurar e otimizar MariaDB ou MySQL vai além da instalação — o tuning correto e a escolha da versão certa fazem diferença real na estabilidade e velocidade das suas aplicações. A AviraHost oferece planos de hospedagem com suporte técnico especializado para auxiliar nesse processo.

Conheça os planos de hospedagem da AviraHost