Alojar PostgreSQL num VPS: dimensionar a memória e o disco

Partir do volume útil

A memória de um servidor de base de dados serve antes de mais de cache: uma página lida em memória é servida muito mais depressa do que uma página lida em disco, mesmo NVMe. A pergunta não é, por isso, apenas «quanto pesa a base?», mas «que parte é lida com frequência?». Uma base de 50 GB da qual só os últimos doze meses são consultados trabalha talvez sobre 8 GB.

Numa base 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 uma base futura, estime tabela a tabela: número de linhas esperadas a um ano × tamanho médio de uma linha, e depois acrescente os índices, que pesam habitualmente de 30 a 100 % dos dados. Exemplo: 2 milhões de linhas por mês, de 500 bytes cada, fazem 12 GB de dados a um ano, e 18 a 24 GB com os índices.

A memória: as definições de partida

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

Estes valores pressupõem uma base de dados sozinha no servidor. Se a aplicação correr ao lado, retire primeiro a memória dela (processos, cache, compilação) e aplique as percentagens ao resto: um servidor de 8 GB que corre uma aplicação de 3 GB ajusta-se como uma base 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ó produz efeito quando o PostgreSQL reinicia; os outros parâmetros recarregam-se sem interrupção, com SELECT pg_reload_conf();.

Para saber se a memória chega, leia a taxa de leitura em cache. Numa aplicação de gestão ou num site, fica acima 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 ligações: um processo cada

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

A resposta certa é um agregador de ligações: o PgBouncer, em modo transaction, faz com que algumas dezenas de ligações reais sejam partilhadas por centenas de ligações da aplicação. As frameworks têm também o seu próprio pool (SQLAlchemy, Prisma, HikariCP): ajuste o seu tamanho ao número de vCPU do servidor da base de dados, e não ao número de utilizadores.

O disco: volume, margem e registo de transações

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

• Os dados e os índices, e o seu crescimento ao longo de um ano.
• O registo de transações (WAL): 1 GB por predefinição entre dois pontos de controlo (max_wal_size), mais durante uma importação massiva, e mais ainda se o arquivo do registo se atrasar.
• Os ficheiros temporários das ordenações que excedem work_mem.
• O espaço de uma reorganização: VACUUM FULL e a reconstrução de um índice escrevem uma cópia completa antes de libertar a antiga.
• As exportações locais, se guardar cópias de segurança no servidor antes de as enviar para outro lado.

A regra: o volume a um ano, mais pelo menos 30 % de margem. Não é uma questão de conforto: quando o disco que guarda o registo de transações se enche, o PostgreSQL interrompe o serviço para proteger os seus dados. Vigie a ocupação, e aumente o disco antes dos 80 %.

Do lado do desempenho, cada confirmação de transação espera pela escrita do registo em disco: a latência do armazenamento define o débito de escrita. É aí que um SSD NVMe faz a diferença, muito mais do que nas leituras, que a memória já serve.

O processador: uma consulta, um núcleo

Uma consulta PostgreSQL executa-se num único núcleo, exceto as grandes leituras que o motor paraleliza. O número de vCPU define portanto o número de consultas pesadas tratadas ao mesmo tempo: 2 vCPU chegam para uma aplicação de gestão no lançamento, 4 a 8 servem as bases muito solicitadas e os relatórios pesados.

Antes de acrescentar vCPU, procure as consultas que os consomem. A extensão pg_stat_statements ordena-as 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;

O mesmo servidor que a aplicação, ou um servidor separado?

No lançamento, a base de dados no mesmo servidor que a aplicação é a escolha certa: nenhuma latência de rede entre as duas, uma ligação por socket Unix, um único servidor para copiar e vigiar. Separa-se quando as duas disputam os recursos: uma compilação ou um pico de tráfego que esvazia a cache da base, uma base que precisa de toda a memória para os seus dados, ou exigências de cópia de segurança diferentes.

Segurança e cópias de segurança

• Escuta local: listen_addresses = 'localhost' enquanto só a aplicação do servidor se liga. Se outro servidor tiver de aceder, abra a porta 5432 apenas ao endereço dele, na firewall e no pg_hba.conf.
• Autenticação: método scram-sha-256 no pg_hba.conf, um papel por aplicação, sem privilégios de superutilizador.
• Cópia de segurança lógica diária com pg_dump, copiada para fora do servidor.
• Restauro para um instante preciso: o arquivo contínuo do registo de transações (pgBackRest, WAL-G) permite voltar ao minuto exato antes de um erro, enquanto uma exportação diária leva de volta à véspera.
• Restauro testado: uma cópia de segurança prova-se restaurando-a, numa base de teste, a 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