Banco de dados numa VPS: PostgreSQL ou MySQL
Um banco de dados quase sempre esbarra não no processador, mas na memória e no disco. Se o conjunto de dados em uso cabe no cache, as consultas são rápidas mesmo num servidor barato; se não cabe, quem decide tudo é a velocidade do disco. Veja como escolher entre PostgreSQL e MySQL, quanta memória dar ao banco, que disco contratar e como não perder dados.
Na maioria dos sites e aplicações, a escolha do SGBD já foi feita por você: o WordPress, o Bitrix e a maior parte das plataformas em PHP foram feitos para MySQL, e muitos projetos em Django, Rails e Go usam PostgreSQL por padrão. Se a escolha é livre, os dois dão conta de uma carga típica, e a diferença está no que é mais cômodo para você manter e no que a sua stack suporta.
PostgreSQL ou MySQL
- MySQL e MariaDB são o padrão para CMS e lojas virtuais em PHP. Qualquer painel de controle e qualquer hospedagem compartilhada os suportam, há mais tutoriais prontos para eles, e migrar um site da hospedagem para uma VPS normalmente se resume a um dump e uma importação.
- PostgreSQL é a escolha para aplicações com consultas complexas, relatórios e integridade rigorosa dos dados. Tem mais tipos de dados (JSONB, arrays, intervalos) e suporta extensões como PostGIS para dados geográficos e pgvector para busca vetorial.
Se o projeto é novo e a plataforma não impõe o SGBD, fique com aquele que a equipe conhece: num servidor com 4–8 GB de memória, a diferença de velocidade entre os dois é menor que a diferença entre um banco bem configurado e um mal configurado. Trocar de SGBD num projeto em produção sai caro, por isso a decisão é tomada uma vez só.
Quanta memória dar ao banco
Os dois SGBDs mantêm os dados mais usados num cache próprio, e o tamanho dele é a configuração mais importante depois da instalação. Por padrão ele é pequeno, 128 MB em ambos, então sem ajuste um banco num servidor com 8 GB de memória quase não aproveita essa memória.
- PostgreSQL: segundo a documentação, num servidor dedicado ao banco com 1 GB de memória ou mais, um valor inicial razoável para
shared_buffersé 25% da memória. Passar de 40% dificilmente ajuda, porque o PostgreSQL também se apoia no cache de arquivos do sistema operacional. - MySQL (InnoDB): segundo a documentação do MySQL 8.4, em servidores dedicados o buffer pool
innodb_buffer_pool_sizecostuma receber até 80% da memória física.
A palavra-chave nos dois casos é «dedicado». Se na mesma VPS rodam o servidor web, o PHP-FPM, o Redis e filas, sobra menos para o banco: num servidor com 4 GB que também hospeda o site, é razoável dar ao buffer pool do MySQL 1–1,5 GB, e não 3. O resto vai para os processos da aplicação e para a margem; caso contrário, o servidor passa a usar swap e o banco fica mais lento do que com um cache pequeno.
A referência para o tamanho do servidor é o volume de dados «quentes»: as tabelas e os índices acessados o tempo todo. Se eles cabem inteiros no cache, a maioria das leituras nem chega ao disco. Pelo catálogo da accsly.io em novembro de 2026, o preço mediano de uma VPS com 4 GB de memória é US$ 22 por mês; com 8 GB, US$ 41; com 16 GB, US$ 74; com 32 GB, US$ 134. Os preços estão em rublos no catálogo; aqui foram convertidos pelo câmbio de 7 de novembro de 2026 e arredondados. Mais sobre como dimensionar memória e núcleos no artigo Quanta memória e quantos núcleos um site precisa; planos com 16 GB ou mais estão na página VPS com 16 GB de RAM.
Disco e IOPS
Quando os dados não cabem na memória, e também a cada gravação, o banco acessa o disco com pequenas operações aleatórias. O que importa aqui não é o volume nem a velocidade sequencial da descrição do plano, e sim o número de operações de entrada e saída por segundo (IOPS) e a latência. É justamente nessas operações que o NVMe ganha do SSD SATA, e um disco rígido não serve de jeito nenhum para um banco em produção: ele faz centenas de operações por segundo, enquanto um SSD faz dezenas de milhares.
Pelo catálogo da accsly.io em novembro de 2026, o NVMe aparece em 41% dos 29.603 planos de VPS, e entre os planos maiores a fatia é mais alta: 38% nos planos com 2 GB de memória e 45% nos planos com 32 GB. A comparação entre os discos está no artigo NVMe ou SSD: faz diferença para um site?, e a seleção de planos em VPS com NVMe.
Os números da descrição de um plano de VPS são um teto: o disco é dividido com os vizinhos do servidor físico, e muitos provedores limitam o IOPS por máquina virtual. A velocidade real é medida depois da compra, enquanto ainda dá para devolver o servidor, com o utilitário fio e um teste de leitura e gravação aleatórias em blocos de 4–16 KB. Como fazer isso no período de teste está no artigo Como testar ping e velocidade de uma VPS antes de pagar.
Backups e réplicas
O snapshot de disco do provedor é uma cópia cômoda, mas não a mais confiável para um banco: um snapshot feito durante uma gravação pode exigir recuperação como depois de uma falha, e ele normalmente fica guardado no mesmo provedor. Para o banco, faça cópias próprias com as ferramentas do SGBD:
- Dump lógico:
pg_dumpno PostgreSQL oumysqldumpno MySQL. Para tabelas InnoDB, o dump é feito com a opção--single-transaction; assim, como diz a documentação do mysqldump, ele sai consistente sem bloquear as tabelas. Serve para bancos de até dezenas de gigabytes; restaurar um banco grande a partir de um dump pode levar horas. - Recuperação para um ponto no tempo: uma cópia completa dos arquivos do banco mais um arquivo contínuo do log de alterações. No PostgreSQL, isso é o arquivamento de WAL; no MySQL, o log binário. Assim é possível voltar ao minuto anterior a um
DELETEerrado, e não à noite de ontem.
As cópias ficam fora do servidor do banco, num armazenamento de objetos ou numa VPS separada em outro data center, e são testadas regularmente com uma restauração. As regras gerais de backup estão no artigo Backups de VPS: estratégias e ferramentas, e os armazenamentos para as cópias, no artigo Armazenamento de arquivos numa VPS.
Uma réplica é uma segunda cópia do banco em outro servidor, que recebe as alterações quase na hora: replicação em streaming no PostgreSQL, replicação no MySQL. Ela permite trocar rapidamente de servidor se o principal falhar e aliviá-lo, mandando os relatórios para a réplica. Mas não substitui o backup: uma tabela apagada por engano some também da réplica em frações de segundo.
Banco gerenciado ou próprio na VPS
Os provedores de nuvem oferecem bancos gerenciados: você recebe um endereço para conectar, e a instalação, as atualizações, os backups e as réplicas ficam por conta do provedor. No Amazon RDS, por exemplo, os backups automáticos são guardados por até 35 dias, com recuperação para um ponto no tempo.
- O banco gerenciado compensa quando ninguém na equipe está disposto a responder pelo banco, quando é preciso alta disponibilidade com troca automática de servidor ou quando o tempo fora do ar custa mais que o acréscimo de preço. Os contras: a mesma memória e o mesmo disco saem bem mais caros que numa VPS, parte das configurações e extensões fica indisponível e mudar de provedor é mais complicado.
- O banco próprio na VPS é mais barato e dá controle total sobre a versão, as configurações e as extensões. Em troca, as atualizações, os backups, o monitoramento do espaço em disco e os testes de restauração são trabalho seu. Mais sobre a diferença entre as abordagens no artigo Servidor em nuvem ou VPS.
Um meio-termo comum para um projeto pequeno é o banco na mesma VPS do site, com dump diário e arquivamento do log num armazenamento separado. Quando o banco cresce até alguns gigabytes de dados «quentes» ou começa a atrapalhar a aplicação, ele é levado para um servidor separado com NVMe, e a porta do banco é fechada para a internet, com acesso liberado só a partir dos endereços da aplicação. Planos para esse servidor estão nas páginas VPS para PostgreSQL, VPS para MySQL e VPS para banco de dados. Vale incluir logo o espaço em disco e a latência das consultas no monitoramento: disco cheio é a causa mais comum de um banco parar.