Hospedar PostgreSQL em um VPS: dimensionar memória e disco

Partir do volume útil

A memória de um servidor de banco de dados serve primeiro de cache: uma página lida da memória é servida muito mais rápido que uma página lida do disco, mesmo NVMe. A pergunta, então, não é só “quanto pesa o banco?”, mas “que parte dele é lida com frequência?”. Um banco de 50 GB em que só os últimos doze meses são consultados talvez trabalhe com 8 GB.

Em um banco existente, duas consultas dão o volume total e as maiores tabelas, índices incluídos:

SELECT pg_size_pretty(pg_database_size(current_database()));

SELECT relname AS nome,
       pg_size_pretty(pg_total_relation_size(relid)) AS tamanho_com_indices
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

Para um banco ainda por criar, estime tabela por tabela: número de linhas esperadas em um ano × tamanho médio de uma linha e, depois, acrescente os índices, que costumam pesar de 30 a 100% dos dados. Exemplo: 2 milhões de linhas por mês, de 500 bytes cada, dão 12 GB de dados em um ano, e 18 a 24 GB com os índices.

A memória: as configurações iniciais

O PostgreSQL guarda as páginas lidas em dois níveis: o próprio cache (shared_buffers) e o cache de arquivos do sistema. A documentação do PostgreSQL recomenda partir de 25% da memória para shared_buffers em um servidor dedicado, e observa que, acima de 40%, o ganho se torna raro: o restante beneficia o cache do sistema e as ordenações.

Esses valores supõem um banco sozinho no servidor. Se a aplicação roda ao lado, desconte primeiro a memória dela (processos, cache, build) e aplique as porcentagens ao restante: um servidor de 8 GB que roda uma aplicação de 3 GB se ajusta como um banco de 5 GB.

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
random_page_cost = 1.1

shared_buffers só entra em vigor quando o PostgreSQL reinicia; os outros parâmetros são recarregados sem interrupção, com SELECT pg_reload_conf();.

Para saber se a memória basta, leia a taxa de leitura em cache. Em uma aplicação de gestão ou em um site, ela passa de 99%:

SELECT round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS taxa_cache
FROM pg_stat_database
WHERE datname = current_database();

As conexões: um processo para cada uma

O PostgreSQL abre um processo por conexão e aceita 100 por padrão (max_connections). Cada processo ocupa alguns megabytes em repouso, mais quando ordena ou faz hash de dados (work_mem, às vezes várias vezes na mesma consulta). Aumentar max_connections para 500 para acompanhar uma aplicação que abre conexões demais é expor o servidor a ficar sem memória no primeiro pico.

A boa resposta é um pool de conexões: o PgBouncer, no modo transaction, faz algumas dezenas de conexões efetivas com o banco atenderem centenas de conexões da aplicação. Os frameworks também têm o próprio pool (SQLAlchemy, Prisma, HikariCP): ajuste o tamanho dele pelo número de vCPU do servidor do banco, e não pelo número de usuários.

O disco: volume, margem e log

O disco de um servidor PostgreSQL guarda mais do que as tabelas:

• Os dados e os índices, e o crescimento deles em um ano.
• O log de transações (WAL): 1 GB por padrão entre dois checkpoints (max_wal_size), mais durante uma importação em massa, e mais ainda se o arquivamento do log atrasar.
• Os arquivos temporários das ordenações que ultrapassam work_mem.
• O espaço de uma reorganização: VACUUM FULL e a reconstrução de um índice gravam uma cópia completa antes de liberar a antiga.
• As exportações locais, se você guarda backups no servidor antes de enviá-los para outro lugar.

A regra: o volume em um ano, mais pelo menos 30% de margem. Não é conforto: quando o disco que guarda o log de transações enche, o PostgreSQL se desliga para proteger os dados. Monitore a ocupação e amplie antes de 80%.

Do lado do desempenho, cada commit espera a gravação do log em disco: a latência do armazenamento define a vazão de escrita. É aí que um SSD NVMe faz a diferença, muito mais do que nas leituras, que a memória já atende.

O processador: uma consulta, um núcleo

Uma consulta PostgreSQL é executada em um único núcleo, exceto as grandes leituras que o motor paraleliza. O número de vCPU define, portanto, quantas consultas pesadas são processadas ao mesmo tempo: 2 vCPU bastam para uma aplicação de gestão no lançamento, 4 a 8 atendem bancos muito solicitados e relatórios pesados.

Antes de acrescentar vCPU, procure as consultas que os consomem. A extensão pg_stat_statements as classifica por tempo total:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls, round(total_exec_time) AS ms_total,
       round(mean_exec_time::numeric, 1) AS ms_medio, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Mesmo servidor da aplicação, ou servidor separado?

No lançamento, o banco no mesmo servidor da aplicação é a escolha certa: nenhuma latência de rede entre os dois, uma conexão por socket Unix, um único servidor para fazer backup e monitorar. Separa-se quando os dois disputam os recursos: um build ou um pico de tráfego que esvazia o cache do banco, um banco que precisa de toda a memória para os dados, ou exigências de backup diferentes.

Segurança e backups

• Escuta local: listen_addresses = 'localhost' enquanto apenas a aplicação do servidor se conectar. Se outro servidor precisar acessar o banco, abra a porta 5432 somente para o endereço dele, no firewall e no pg_hba.conf.
• Autenticação: método scram-sha-256 no pg_hba.conf, um papel (role) por aplicação, sem privilégios de superusuário.
• Backup lógico diário com pg_dump, copiado para fora do servidor.
• Restauração em um ponto no tempo: o arquivamento contínuo do log (pgBackRest, WAL-G) permite voltar ao minuto exato antes de um erro, enquanto uma exportação diária leva de volta ao dia anterior.
• Restauração testada: um backup se comprova restaurando-o, em um banco de teste, em intervalos regulares.

pg_dump -Fc -d minha_base -f minha_base-$(date +%F).dump
createdb minha_base_teste
pg_restore -d minha_base_teste minha_base-2026-10-29.dump