VPS para MySQL e MariaDB no Brasil

Resposta direta

Para hospedar MySQL ou MariaDB em uma VPS no Brasil, comece avaliando três pontos: memória suficiente para manter índices e dados frequentes em cache, disco SSD ou NVMe com boa latência de escrita, e proximidade entre aplicação e banco. Um ambiente pequeno pode funcionar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD, mas produção com tráfego real costuma ficar mais confortável a partir de 4 vCPUs, 8 GB de RAM, armazenamento rápido e política clara de backup. A localização importa porque cada consulta feita pela aplicação soma tempo de rede. Se o público, a API e o banco estão no Brasil, uma região brasileira tende a reduzir a latência. O provedor deve ser escolhido pelo conjunto, não por um recurso isolado.

Resumo rápido

• Para MySQL e MariaDB, RAM costuma ser mais crítica que CPU em cargas com muitos índices e consultas repetidas.
• NVMe ajuda em escrita, leitura aleatória, tabelas grandes, logs binários e operações de backup, mas não corrige query mal escrita.
• Uma base pequena em produção pode começar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD, com monitoramento desde o primeiro dia.
• Para lojas virtuais, ERPs e SaaS, 4 vCPUs, 8 GB de RAM e disco rápido reduzem gargalos comuns em horários de pico.
• Backup precisa ter retenção, criptografia, cópia fora da VPS e teste de restauração, não apenas um arquivo gerado por cron.
• Banco e aplicação devem ficar na mesma região ou em regiões próximas para evitar latência acumulada em várias consultas.
• VPS tradicional, Cloud Server e instância cloud podem servir, mas diferem em elasticidade, rede, painel, storage e recuperação.

Como MySQL e MariaDB usam recursos em uma VPS

MySQL e MariaDB são bancos relacionais sensíveis a memória, disco e padrão de consulta. Em um site simples, o banco passa boa parte do tempo respondendo leituras pequenas. Em um ERP, marketplace ou SaaS, ele precisa lidar com filtros, joins, transações, locks, relatórios e escrita constante. Por isso, a pergunta correta não é apenas quanta RAM a VPS tem. A pergunta é quanto do conjunto de dados ativo cabe em memória, quantas conexões simultâneas chegam ao banco e quanto tempo o disco leva para confirmar gravações.

O InnoDB, mecanismo mais usado em MySQL e MariaDB, trabalha melhor quando o buffer pool consegue guardar páginas de dados e índices acessados com frequência. Em uma VPS com 4 GB de RAM, por exemplo, reservar entre 2 GB e 2,5 GB para innodb_buffer_pool_size pode ser razoável se o servidor roda apenas o banco. Se a mesma máquina também hospeda Nginx, PHP, Redis e workers, essa reserva precisa ser menor. Esse é um erro comum em projetos pequenos: colocar tudo na mesma VPS, subir o número de conexões e depois culpar apenas o provedor quando aparece swap.

A CPU entra com força em consultas complexas, ordenações, agregações, compressão, criptografia TLS e replicação. Duas vCPUs atendem bem um blog ou sistema interno leve, mas relatórios com GROUP BY, ORDER BY sem índice adequado e buscas em tabelas grandes podem saturar processador rapidamente. Antes de aumentar plano, vale analisar EXPLAIN, índices compostos e consultas lentas.

Também existe diferença entre VPS tradicional, Cloud Server e cloud instance. A VPS tradicional costuma ser uma fatia virtualizada de um servidor físico, com recursos previsíveis, mas elasticidade menor. O Cloud Server geralmente oferece upgrades mais simples, painel com snapshots e rede integrada, dependendo do provedor. A cloud instance em hyperscalers pode trazer mais serviços gerenciados ao redor, porém cobra complexidade operacional. Se você ainda está comparando conceitos, o guia de PostgreSQL em VPS ajuda a entender decisões parecidas em outro banco relacional.

Dimensionamento de CPU e RAM para bancos relacionais

O dimensionamento começa pelo tamanho do conjunto ativo, não pelo tamanho total do banco. Uma base com 80 GB em disco pode ter apenas 5 GB realmente acessados durante o dia. Outra base com 12 GB pode exigir muita RAM porque usuários fazem filtros variados em tabelas grandes. Para MySQL e MariaDB, a meta é manter índices e páginas quentes em memória, evitando leitura aleatória constante no disco. Quando o servidor começa a usar swap, a experiência piora rápido: consultas que respondiam em 40 ms podem passar para centenas de milissegundos.

Para produção básica, 2 vCPUs e 4 GB de RAM são um ponto de partida honesto. Esse perfil atende APIs pequenas, painéis administrativos, blogs com tráfego moderado e sistemas internos com poucas dezenas de usuários simultâneos. Uma configuração inicial poderia usar Ubuntu LTS, MariaDB 10.11 ou MySQL 8.0, innodb_buffer_pool_size em torno de 2 GB, max_connections entre 80 e 150, logs de consultas lentas ativados e swap pequena apenas como rede de segurança. Se a aplicação PHP ou Node.js roda junto, reduza o buffer pool e monitore memória livre.

Cargas médias pedem 4 vCPUs e 8 GB de RAM. Esse perfil combina com WooCommerce, sistema de assinaturas, API com filas e dashboards. Com 8 GB, o banco pode receber 5 GB a 6 GB de buffer pool se estiver isolado. Também dá para separar Redis e aplicação em outra VPS, deixando o banco respirar. Em times que fazem deploy frequente, essa separação reduz o risco de uma atualização da aplicação derrubar o banco por falta de memória.

Cargas maiores começam em 8 vCPUs e 16 GB de RAM, mas não adianta escalar sem medir. Use SHOW GLOBAL STATUS, Performance Schema, mysqltuner com critério, métricas do sistema e slow query log. CPU alta com disco ocioso aponta para consulta pesada ou falta de índice. Disco saturado com CPU baixa aponta para I/O. Memória cheia com swap indica ajuste de cache, conexões ou separação de serviços. O guia sobre como escolher CPU, RAM e NVMe aprofunda esse raciocínio para outros tipos de workload.

Disco NVMe, IOPS e configuração de armazenamento

O disco é decisivo em bancos relacionais porque quase tudo passa por leitura, escrita, logs e sincronização. SSD já mudou muito o cenário em relação a discos mecânicos, mas NVMe reduz latência e aumenta a quantidade de operações por segundo em muitos ambientes. Isso aparece em consultas que precisam buscar páginas não cacheadas, em escrita concorrente, em criação de índices, em restauração de dumps e em backups físicos. Ainda assim, NVMe não faz milagre. Uma consulta sem índice em tabela com milhões de linhas continuará cara, apenas vai sofrer um pouco menos.

Para MySQL e MariaDB, observe três métricas: latência de leitura, latência de escrita e IOPS sustentado. Latência baixa ajuda em operações pequenas e frequentes. IOPS sustentado importa quando várias consultas disputam o disco. Throughput, medido em MB/s, aparece em dump, restore, cópia de arquivos e leitura sequencial. Um banco de 30 GB com muitas buscas aleatórias pode sofrer mais com IOPS do que um banco de 200 GB usado em relatórios sequenciais noturnos.

Uma configuração prática para VPS dedicada ao banco começa com sistema em partição simples, disco SSD ou NVMe, filesystem ext4 ou XFS e monitoramento de iostat. Em produção, evite deixar o volume com mais de 80% de uso. O MySQL precisa de espaço para tabelas temporárias, binlogs, arquivos de undo, backups locais temporários e operações de manutenção. Se o banco tem 50 GB, não escolha uma VPS com 60 GB apenas porque cabe hoje. Prefira 100 GB ou mais, dependendo da retenção de logs e rotina de backup.

Alguns parâmetros merecem cuidado. innodb_flush_log_at_trx_commit=1 favorece durabilidade, mas aumenta pressão de escrita. sync_binlog=1 também protege replicação e recuperação, com custo de I/O. Em lojas e sistemas financeiros, segurança de dados costuma valer mais que alguns milissegundos. Em ambientes de staging, dá para relaxar. Provedores podem oferecer SSD, NVMe, volumes adicionais e snapshots, mas disponibilidade muda por plano e região. No caso da LetsCloud, por exemplo, armazenamento NVMe, localidades como São Paulo, Fortaleza ou Miami e recursos de snapshot devem ser confirmados no plano específico antes de publicar qualquer afirmação fechada.

Latência no Brasil e impacto nas consultas

Latência não é detalhe quando banco e aplicação conversam muitas vezes por requisição. Uma página que executa 20 consultas sente cada ida e volta pela rede. Se a aplicação está em São Paulo e o banco nos Estados Unidos, uma latência de 120 ms a 180 ms pode transformar uma tela simples em uma experiência lenta, mesmo com CPU sobrando. Já aplicação e banco na mesma região ou no mesmo datacenter podem operar com latência muito menor, frequentemente na casa de poucos milissegundos em redes internas, dependendo do provedor e da arquitetura.

Para público brasileiro, existem dois cenários comuns. No primeiro, aplicação, banco e usuários estão no Brasil. Aqui, uma VPS ou Cloud Server em região brasileira tende a reduzir o tempo de resposta percebido, principalmente em sistemas administrativos, e-commerce, APIs transacionais e plataformas B2B. No segundo, o público é global ou a aplicação já usa CDN, filas e cache agressivo. Nesse caso, uma região fora do Brasil pode funcionar, desde que banco e aplicação fiquem próximos entre si. O erro é colocar a aplicação em uma região e o banco em outra sem motivo técnico.

A regra prática é simples: mantenha banco e aplicação na mesma região sempre que possível. Se precisar separar, use rede privada do provedor, criptografia em trânsito e medições reais com ping, mtr e testes de consulta. Medir apenas ping não basta, mas ajuda a detectar rotas ruins. Faça também um teste com a aplicação executando fluxo real: login, listagem, filtro, checkout, gravação e relatório.

Em arquiteturas maiores, a latência pode ser controlada com cache, filas e réplicas de leitura. Redis reduz consultas repetidas. Filas tiram tarefas lentas do caminho do usuário. Réplicas ajudam relatórios e leitura pesada, mas trazem atraso de replicação e mais operação. Para MySQL e MariaDB em VPS, comece simples e mensurável. Primeiro coloque aplicação e banco perto. Depois otimize consultas. Só então adicione camadas que aumentam complexidade.

Backup, snapshots e recuperação de desastres

Backup de banco relacional precisa ser desenhado pensando na restauração. Ter um arquivo .sql.gz gerado de madrugada não garante recuperação se ninguém testa o restore, se o arquivo está corrompido ou se ele fica no mesmo disco que pode falhar. Em uma VPS para MySQL ou MariaDB, combine pelo menos duas estratégias: backup lógico com mysqldump ou mariadb-dump para bases menores, e backup físico com ferramentas como Percona XtraBackup ou MariaDB Backup para bases maiores e janelas de manutenção curtas.

Para bancos pequenos, um dump diário pode resolver. Exemplo: banco de 5 GB, retenção de 7 dias, envio para storage externo compatível com S3, criptografia antes do upload e alerta em caso de falha. Para bancos de 50 GB ou mais, dump completo diário pode demorar, gerar carga alta e produzir arquivos grandes. Nesse caso, backup físico incremental passa a fazer sentido. Snapshots do provedor ajudam bastante para recuperação rápida da VPS inteira, mas não substituem backup consistente do banco. Um snapshot feito no meio de escrita intensa pode exigir recuperação do InnoDB e, em alguns casos, gerar surpresa.

O ideal é montar uma política com RPO e RTO. RPO responde quanto dado você aceita perder. RTO responde quanto tempo pode ficar fora. Um blog pode aceitar restauração de ontem. Um e-commerce talvez aceite no máximo alguns minutos, usando binlogs para recuperação point-in-time. Ative binlogs quando precisar reconstruir transações entre o último backup e o momento da falha, mas monitore espaço em disco. Binlogs esquecidos são causa clássica de volume cheio.

Também existe o lado operacional. Salve backups fora da VPS, use credenciais com permissão mínima, criptografe arquivos, documente o passo a passo de restauração e rode testes mensais em um ambiente separado. O artigo sobre VPS com backup automático detalha critérios para avaliar políticas de retenção, snapshots e automação sem depender apenas de promessas comerciais. Em qualquer provedor, confirme se backup automático é incluso, opcional ou cobrado à parte antes de tomar decisão.

Segurança, operação e monitoramento em produção

Banco em VPS exige disciplina de segurança. O primeiro passo é não expor MySQL ou MariaDB publicamente na internet sem necessidade. A porta 3306 deve ficar fechada para o mundo, liberada apenas para IPs conhecidos, rede privada ou túnel seguro. Se a aplicação está na mesma VPS, use localhost. Se está em outra máquina, prefira rede privada do provedor. Quando acesso remoto for inevitável, combine firewall, usuário com permissões restritas, TLS e rotação de senha.

A configuração do sistema operacional também pesa. Use uma distribuição LTS, aplique atualizações de segurança, desative login SSH por senha, use chaves, crie usuário administrativo sem root direto e configure firewall com regras explícitas. Ferramentas como UFW, Fail2ban e auditoria de logs ajudam, mas não substituem boa modelagem de acesso. No banco, evite usuário único com privilégios globais para toda aplicação. Um usuário para aplicação, outro para backup e outro para leitura administrativa reduzem o estrago em caso de vazamento.

Monitoramento precisa ir além de CPU e RAM. Para MySQL e MariaDB, acompanhe conexões ativas, queries lentas, uso do buffer pool, locks, deadlocks, taxa de leitura em disco, crescimento de binlogs, espaço livre, tempo de backup e atraso de replicação se houver réplica. Um alerta de disco em 90% pode chegar tarde demais quando binlogs crescem rápido. Configure aviso em 70% e 80%, com ação clara.

Logs também merecem rotina. Ative slow query log com threshold realista, por exemplo 500 ms em APIs sensíveis ou 1 segundo em sistemas administrativos. Revise as consultas mais caras semanalmente. Em muitos casos, um índice composto resolve mais que dobrar a VPS. Se uma tabela de pedidos recebe filtros por cliente_id, status e created_at, o índice precisa refletir o padrão de busca. Operação boa é isso: medir, ajustar, testar, documentar e repetir.

Tabela comparativa de perfis de VPS para MySQL e MariaDB

A tabela abaixo não é um comparativo de preços nem uma recomendação fechada de provedor. Ela serve para dimensionar perfis comuns. Recursos como tipo de storage, largura de banda, região, backup e snapshots variam conforme fornecedor, plano e localidade. Antes de contratar, revise a página oficial do provedor e valide se a região brasileira, o disco NVMe e os recursos de recuperação estão disponíveis no plano escolhido.

Perfil de uso	Configuração inicial sugerida	Banco típico	Pontos de atenção	Sinal para upgrade
Projeto pequeno ou sistema interno	2 vCPUs, 4 GB RAM, 60 GB SSD	Até 10 GB, poucas dezenas de usuários	Ajustar buffer pool, limitar conexões, backup diário externo	Swap frequente, CPU acima de 80%, consultas lentas recorrentes
E-commerce ou SaaS em crescimento	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	10 GB a 80 GB, picos de acesso	Separar aplicação e banco, ativar slow log, testar restore mensal	I/O alto, locks em checkout, relatórios afetando usuários
Produção crítica com alta escrita	8 vCPUs, 16 GB RAM, 200 GB NVMe ou volume rápido	80 GB ou mais, transações constantes	Binlogs, backup físico, réplica de leitura, alertas granulares	Latência de escrita alta, fila de queries, restore demorado
BI leve e relatórios internos	4 vCPUs, 16 GB RAM, 150 GB SSD ou NVMe	Consultas pesadas em horários específicos	Índices para relatórios, agendamento fora do pico, réplica se necessário	Relatórios travando aplicação principal

Em bases pequenas, o maior ganho costuma vir de índices corretos, cache e backup bem feito. Em bases médias, separar aplicação e banco reduz interferência entre deploys, workers e consultas. Em cargas críticas, o problema passa a ser continuidade: como restaurar, como replicar, como trocar de plano sem janela longa e como evitar que um relatório pesado afete o checkout.

Também há diferenças entre provedores. DigitalOcean, Vultr, Linode ou Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hetzner, Contabo, Hostinger, HostGator, Locaweb e LetsCloud atendem públicos diferentes. Alguns focam painel simples, outros rede global, outros custo, outros serviços gerenciados ao redor. Para banco relacional em produção no Brasil, filtre primeiro por região, latência para sua aplicação, tipo de disco, política de backup, suporte operacional e clareza da documentação. Preço deve entrar depois, com revisão humana dos valores atuais.

Recomendações por perfil

Dev solo e projetos pequenos

Para um desenvolvedor solo, freelancer ou projeto interno, a prioridade é simplicidade com margem de segurança. Uma VPS com 2 vCPUs, 4 GB de RAM e 60 GB de SSD atende muitos sistemas Laravel, WordPress, Node.js ou APIs pequenas com MySQL e MariaDB. Se aplicação e banco ficarem na mesma máquina, seja conservador: reserve cerca de metade da memória para o banco, deixe espaço para web server, runtime, cache e atualizações. Use backup diário externo, slow query log e firewall desde o início. Não espere o primeiro incidente para criar rotina. Esse perfil não precisa de arquitetura complexa, mas precisa de disciplina básica: atualizar sistema, testar restore e acompanhar disco livre.

Time pequeno com aplicação em produção

Times pequenos que já têm clientes pagantes devem tratar o banco como serviço crítico. O caminho mais equilibrado costuma ser separar aplicação e banco em VPS diferentes, usando rede privada quando disponível. Um ponto de partida razoável é 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe para o banco, com a aplicação em outra instância. Essa separação evita que deploy, build, fila ou pico de PHP consuma memória do banco. Também facilita manutenção: você pode reiniciar aplicação sem tocar no MySQL. Nesse perfil, backup físico ou lógico precisa ter alerta, retenção e teste mensal. Monitore slow queries, locks, I/O e crescimento de binlogs.

Produção crítica e crescimento previsível

Ambientes críticos pedem planejamento antes da dor. Se o banco sustenta checkout, faturamento, prontuário, assinatura ou operação B2B, comece pensando em RPO, RTO, replicação e restauração. Uma configuração inicial pode usar 8 vCPUs, 16 GB de RAM, 200 GB de NVMe ou volume rápido, backup físico incremental, binlogs e réplica de leitura para relatórios. Isso não elimina a necessidade de otimizar consultas. Pelo contrário, quanto maior a base, mais caro fica corrigir depois. Teste failover, documente credenciais, simule restauração em ambiente isolado e revise capacidade a cada ciclo de crescimento. Para esse perfil, contratar apenas pelo menor preço costuma sair caro quando ocorre falha, lentidão ou perda de dados.