MySQL grátis na internet: até onde ele serve e como tirar o sistema de lá

O sistema de inscrições de um curso livre nasceu num fim de semana: um MySQL gratuito criado em cinco minutos, com o endereço e a senha colados no config.php. Dois anos depois, a tabela tem 1.800 alunos com nome, e-mail e telefone, ninguém sabe se existe backup e o serviço mandou um e-mail avisando que contas inativas serão apagadas. A resposta curta: banco gratuito sem contrato serve para estudo com dado fictício; quando entra dado de pessoa real, ele precisa ir para um lugar que você controla, com backup que você já restaurou. A migração cabe numa tarde se você seguir a ordem certa.

O guia sobre hospedagem grátis que não é produção trata do site inteiro. Aqui o foco é o banco: o que avaliar e como sair sem perder registros.

Por que o banco gratuito vira problema

Serviço gratuito precisa pagar a conta de alguma forma. Às vezes é anúncio, às vezes é limite apertado que empurra para o plano pago, às vezes é só um projeto pessoal de alguém que pode fechar amanhã. Nenhum desses modelos é errado. O problema é usar sem saber qual é o seu.

Três riscos aparecem juntos. O primeiro é de continuidade: sem contrato, o serviço pode apagar contas, mudar regras ou sair do ar, e o seu backup é o que você mesmo fez. O segundo é de acesso: para o seu servidor conseguir conectar, o banco costuma aceitar conexões da internet inteira, protegido só por usuário e senha. O terceiro é de responsabilidade: se há dado pessoal, quem responde por ele é você, não o serviço gratuito. A LGPD não faz exceção para banco que não custou nada. O guia de adequação à LGPD em sistema pequeno mostra o mínimo.

Como avaliar um banco antes de pôr dado real nele

Responda por escrito, olhando a documentação e os termos do serviço. Se uma resposta for "não sei", ela vale como "não".

• Quem opera e com que compromisso? Existe empresa identificável, termos de uso e alguma forma de contato?
• Backup: o serviço faz? Você consegue baixar e restaurar sozinho, sem depender do suporte?
• Acesso: dá para restringir as conexões ao IP do seu servidor ou a uma rede privada?
• Conexão cifrada: o servidor aceita TLS? Sem isso, usuário, senha e dados viajam abertos.
• Limites: o que acontece quando você passa do espaço ou do número de conexões? Bloqueio, lentidão ou exclusão?
• Saída: como você exporta tudo se quiser ir embora, e com que privilégios?

Para verificar se a conexão atual está cifrada, rode no próprio cliente MySQL, já conectado:

SHOW SESSION STATUS LIKE 'Ssl_cipher';

Valor vazio significa que a sessão está em texto aberto.

Como migrar para um banco que você controla

O destino pode ser um MySQL na sua própria VM, um banco gerenciado de um provedor de nuvem ou o banco incluído numa hospedagem paga. O que importa é ter contrato, backup e acesso restrito. Se o banco ficar numa máquina separada da aplicação, o guia de MySQL em outro servidor mostra como abrir só para quem precisa.

1. Anuncie uma janela curta e coloque o sistema em modo de manutenção, para ninguém gravar durante a cópia.
2. Gere o dump no serviço gratuito.
3. Crie o banco e um usuário da aplicação no destino, com privilégios só naquele banco.
4. Importe o dump e compare a contagem de linhas das tabelas principais.
5. Troque a configuração da aplicação para o novo endereço, sem senha no código.
6. Teste as operações principais, tire o modo de manutenção e mantenha o banco antigo intacto por alguns dias.
7. Depois de confirmar, apague os dados do serviço gratuito.

O dump e a importação

mysqldump -h sql.servico-gratis.example -u u48213 -p \
  --single-transaction --routines --triggers \
  --no-tablespaces --default-character-set=utf8mb4 \
  u48213_cursos > cursos-2026-10-17.sql

O --single-transaction garante uma fotografia consistente das tabelas InnoDB sem travar o banco. O --no-tablespaces evita o erro de privilégio PROCESS que aparece no MySQL 8 quando o usuário do serviço gratuito não tem esse direito, o que é comum. O -p sem valor faz o cliente perguntar a senha, em vez de deixá-la no histórico do terminal.

CREATE DATABASE cursos CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
CREATE USER 'cursos_app'@'10.0.0.%' IDENTIFIED BY 'gere-uma-senha-longa-aqui';
GRANT SELECT, INSERT, UPDATE, DELETE ON cursos.* TO 'cursos_app'@'10.0.0.%';

mysql -h 10.0.0.5 -u admin -p cursos < cursos-2026-10-17.sql

A collation utf8mb4_0900_ai_ci é a padrão do MySQL 8. Se o destino for MariaDB ou uma versão mais antiga, use a collation que o servidor oferece. Se o dump contém procedimentos, funções ou triggers, a importação pode exigir privilégios extras ou ajuste da cláusula DEFINER, porque o usuário de origem não existe no destino.

Confira antes de virar a chave

Rode a mesma consulta nos dois bancos e compare. No curso do exemplo:

SELECT 'alunos' AS tabela, COUNT(*) AS linhas FROM alunos
UNION ALL SELECT 'inscricoes', COUNT(*) FROM inscricoes
UNION ALL SELECT 'pagamentos', COUNT(*) FROM pagamentos;

Os números precisam ser idênticos: 1.800 alunos lá, 1.800 aqui. Abra também três registros com acento no nome e confira se aparecem certos. Acento quebrado depois de migração quase sempre é conjunto de caracteres diferente entre dump e importação, como explica o guia sobre acentos que quebram no banco.

A troca da conexão

Tire o endereço e a senha do código. A aplicação lê do ambiente, e o arquivo de configuração fica fora do Git:

<?php
try {
    $pdo = new PDO(
        'mysql:host=' . getenv('DB_HOST') . ';dbname=' . getenv('DB_NAME') . ';charset=utf8mb4',
        getenv('DB_USER'),
        getenv('DB_PASS'),
        [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
    );
} catch (PDOException $e) {
    error_log('Banco indisponível: ' . $e->getMessage());
    http_response_code(503);
    exit('Sistema em manutenção. Tente novamente em alguns minutos.');
}

Se a senha antiga esteve num repositório, considere-a vazada e não a reaproveite no destino.

Depois da migração, o backup que restaura

Mudar de lugar não adianta se o novo banco também não tem cópia testada. Agende um dump diário, guarde fora da máquina do banco e restaure um deles num banco de teste pelo menos uma vez por mês. O passo a passo está em backup de MySQL que restaura. O dump que você fez para migrar é o primeiro desses backups: guarde-o com data no nome.

Erros comuns

• Colocar dado real "só por enquanto": o provisório vira permanente e o primeiro aviso de exclusão chega quando já há centenas de cadastros.
• Confiar no backup do serviço sem testar: no dia em que você precisa, descobre que não existe ou que só o suporte pode restaurar.
• Usar o usuário administrador na aplicação: uma injeção de SQL ganha poder para apagar o banco inteiro.
• Migrar com o sistema gravando: as inscrições feitas durante a cópia ficam no banco antigo e somem.
• Apagar a origem no mesmo dia: se a contagem tiver passado batida, não há de onde recuperar.
• Deixar a senha no config.php versionado: quem tem acesso ao repositório tem acesso ao banco, hoje e no futuro.

Checklist

• Você sabe quem opera o banco e o que diz o termo de uso.
• Existe um dump recente que você já restaurou num banco de teste.
• O banco aceita conexões só do servidor da aplicação.
• A conexão usa TLS quando passa pela internet.
• A aplicação usa um usuário com privilégios só no próprio banco.
• Endereço e senha vêm do ambiente, não do código.
• Depois da migração, a contagem de linhas bate entre origem e destino.

Se o serviço onde está o seu banco sumisse hoje à noite, de onde viria o cadastro de amanhã de manhã?