VPS para PostgreSQL: CPU, RAM, NVMe e backup

Resposta direta

Para rodar PostgreSQL em VPS com segurança, comece com pelo menos 2 vCPUs, 4 GB de RAM e 80 GB de SSD NVMe para produção pequena. Projetos com API, filas, relatórios ou múltiplos clientes devem considerar 4 vCPUs, 8 GB de RAM e disco NVMe com margem de crescimento. CPU ajuda em consultas complexas, RAM reduz leitura em disco, NVMe melhora latência de escrita e backup protege contra erro humano, falha de disco e deploy ruim. A escolha não deve olhar apenas o preço do plano. Verifique latência para os usuários, política de snapshot, possibilidade de backup fora da VPS, firewall, acesso SSH, monitoramento e facilidade de escalar recursos sem reinstalar o banco.

Resumo rápido

• Para produção básica, uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de NVMe costuma ser um ponto de partida mais seguro que planos de 1 GB.
• PostgreSQL usa CPU em consultas, ordenações, joins, criação de índices, compressão e autovacuum.
• RAM reduz I/O porque permite mais cache de páginas, buffers e conexões simultâneas sem swap.
• NVMe ajuda quando o banco tem muitas escritas, WAL ativo, relatórios pesados ou tabelas grandes.
• Snapshot é útil para rollback rápido, mas não substitui backup lógico, backup físico e teste de restauração.
• Segurança envolve firewall, SSH com chave, PostgreSQL sem exposição pública desnecessária, senhas fortes e permissões mínimas.
• API e banco devem ficar na mesma região sempre que possível para reduzir latência e evitar tráfego público desnecessário.

PostgreSQL em VPS funciona muito bem quando a infraestrutura é planejada como ambiente persistente. O erro comum é tratar o banco como se fosse um serviço leve, instalado ao lado da aplicação sem pensar em I/O, memória, manutenção e recuperação. Uma API Node.js pequena pode parecer tranquila com 1 GB de RAM, mas o banco pode sofrer quando recebe relatórios, migrações, consultas sem índice ou muitas conexões abertas. Se você ainda está escolhendo o tipo de máquina, o guia de como escolher CPU, RAM e NVMe ajuda a montar uma base antes de entrar nos ajustes específicos do PostgreSQL. A boa notícia é que não é preciso começar com uma máquina enorme. O ponto é escolher uma VPS que permita crescer, restaurar dados com confiança e separar o que é economia real do que vira risco operacional.

Como dimensionar uma VPS para PostgreSQL

Dimensionar uma VPS para PostgreSQL começa com uma pergunta simples: o banco vai receber mais leitura, mais escrita ou uma mistura imprevisível dos dois? Uma aplicação de conteúdo, como um painel administrativo com poucos usuários, tende a fazer leituras simples e gravações ocasionais. Um SaaS com eventos, webhooks, filas e relatórios pode gerar muitas inserções por minuto, atualizações concorrentes e consultas agregadas que exigem CPU, RAM e disco ao mesmo tempo. O tamanho do banco em GB importa, mas ele não conta a história toda.

Comece pelo padrão de leitura e escrita

Um banco de 20 GB pode ser mais pesado que um banco de 200 GB se tiver consultas ruins, ausência de índices e muitas transações concorrentes. Para produção pequena, 2 vCPUs e 4 GB de RAM suportam bem uma API com tráfego moderado, desde que o PostgreSQL esteja configurado com limites sensatos. Um exemplo prático seria uma API Laravel ou Node.js com 30 a 80 requisições por minuto, tabelas indexadas e poucos relatórios simultâneos. Nesse cenário, 80 GB de NVMe dá espaço para dados, WAL, logs e crescimento inicial.

Não dimensione só pelo tamanho do banco

Para uma carga mais séria, como um SaaS B2B com 200 a 500 clientes ativos, considere 4 vCPUs, 8 GB de RAM e 160 GB de NVMe. Essa configuração dá margem para autovacuum, backups, criação de índices e picos de uso. Se o banco recebe importações grandes em CSV, filas de processamento ou dashboards com filtros por data, a margem precisa ser maior. Também pense no ciclo de vida dos dados. Tabelas de auditoria, logs de eventos e histórico financeiro crescem rápido. Um banco que começa com 5 GB pode passar de 50 GB em poucos meses se a retenção não for definida. Antes de contratar, estime o crescimento mensal e reserve pelo menos 30% a 40% de espaço livre no disco para manutenção, vacuum, índices temporários e operações de backup.

CPU e RAM: onde o PostgreSQL realmente consome recurso

CPU e RAM trabalham juntas no PostgreSQL, mas resolvem problemas diferentes. CPU aparece quando o banco precisa comparar, ordenar, agrupar, fazer joins, validar constraints, criar índices e processar funções. RAM aparece quando o PostgreSQL precisa manter páginas de dados em cache, buffers compartilhados, conexões, operações de sort e hash. Em uma VPS pequena, o gargalo mais perigoso costuma ser memória insuficiente, porque o sistema entra em swap e a latência sobe de forma brusca.

CPU para consultas, índices e conexões

Para ambientes pequenos, 2 vCPUs são suficientes quando as consultas são simples e bem indexadas. O problema surge quando relatórios fazem varredura em tabelas grandes, como SELECT count(*) com filtros pouco seletivos, joins sem índice ou ordenações em colunas textuais. Nesses casos, 4 vCPUs trazem fôlego para consultas simultâneas e tarefas internas do banco. Uma API que roda jobs em background, por exemplo, pode gerar carga de CPU no PostgreSQL mesmo com poucos usuários logados. O autovacuum também consome CPU e I/O, mas ele é necessário para manter o banco saudável.

RAM para cache, conexões e buffers

A RAM define quanta coisa o banco consegue manter perto da CPU sem ir ao disco. Em uma VPS com 4 GB, uma configuração conservadora poderia usar shared_buffers perto de 1 GB, effective_cache_size entre 2 GB e 3 GB, e work_mem baixo, como 4 MB a 16 MB, dependendo do número de conexões. Em uma VPS com 8 GB, dá para ampliar buffers e suportar mais consultas simultâneas, mas sem exagero. work_mem é aplicado por operação, não por servidor. Se 50 conexões executam ordenações ao mesmo tempo, um valor alto pode consumir memória rapidamente.

Evite rodar PostgreSQL, aplicação, Redis, filas e painel pesado na mesma VPS de 2 GB. Funciona em homologação, mas produção exige margem. Se a aplicação é uma API pública, veja também o guia de VPS para API, porque o número de conexões HTTP e o pool do banco precisam ser planejados juntos. Muitas lentidões atribuídas ao PostgreSQL são, na prática, excesso de conexões abertas sem pool, queries repetidas ou falta de índice em campos usados todos os dias.

NVMe, IOPS e configuração de disco para PostgreSQL

Disco é uma parte sensível do PostgreSQL porque o banco grava dados, índices, logs de transação e arquivos temporários. Mesmo com bastante RAM, escritas precisam chegar ao armazenamento com consistência. NVMe tende a oferecer latência menor e mais IOPS que SSD SATA em muitos ambientes, mas isso depende da implementação do provedor, da contenção do host físico e da política de armazenamento. Por isso, não basta ver a palavra NVMe no plano. Procure informações sobre tipo de disco, limites de I/O, snapshot, backup e comportamento durante picos.

Por que latência de disco pesa tanto

O WAL, Write Ahead Log, é uma das peças centrais do PostgreSQL. Antes de uma transação ser considerada confirmada, o banco precisa registrar informações no WAL. Se o disco responde devagar, commits ficam mais lentos. Em aplicações transacionais, como pagamento, pedidos, estoque ou eventos de auditoria, isso aparece como aumento de tempo de resposta na API. Uma VPS com NVMe pode reduzir esse impacto, especialmente quando há muitas pequenas escritas. O tema é detalhado no guia de VPS com NVMe, que explica por que latência e IOPS importam mais que apenas capacidade em GB.

Separar dados, WAL e backup ajuda?

Em ambientes avançados, separar volumes para dados, WAL e backups pode melhorar organização e reduzir risco de um diretório lotar tudo. Em VPS simples, nem sempre há múltiplos volumes com desempenho isolado. Ainda assim, você pode organizar diretórios e monitorar espaço com alertas. Um exemplo prático: dados em /var/lib/postgresql, logs em partição com rotação configurada e backups enviados para armazenamento externo. Nunca deixe o único backup dentro da mesma VPS. Se o disco corromper, a conta for bloqueada ou um comando apagar diretórios, o backup local pode desaparecer junto.

Reserve espaço. Se o banco ocupa 40 GB, uma VPS com 50 GB de disco já está apertada. Índices, vacuum, dumps compactados, WAL acumulado e logs podem ocupar dezenas de GB em pouco tempo. Para produção, trabalhar com 30% de disco livre é uma regra conservadora. Abaixo de 15%, o risco operacional aumenta. PostgreSQL não gosta de disco cheio, e recuperar um banco nessa condição durante um incidente é muito mais difícil do que pagar por espaço extra antes.

Backup, snapshots e recuperação ponto a ponto

Backup para PostgreSQL não é só baixar um arquivo .sql de vez em quando. Uma política mínima precisa responder três perguntas: quanto dado você aceita perder, quanto tempo pode ficar fora do ar e como provar que a restauração funciona. O primeiro ponto é o RPO, objetivo de ponto de recuperação. Se o RPO é de 24 horas, um dump diário pode bastar para alguns projetos. Se o RPO é de 15 minutos, você precisa arquivar WAL e pensar em recuperação ponto a ponto, conhecida como PITR.

Snapshot não substitui backup lógico

Snapshot de VPS é ótimo para voltar o servidor a um estado anterior, principalmente antes de uma atualização de sistema, migração grande ou mudança de versão do PostgreSQL. Mas snapshot não substitui backup lógico com pg_dump nem backup físico consistente com ferramentas próprias. O snapshot pode carregar arquivos corrompidos, uma configuração errada ou dados já apagados pela aplicação. Além disso, se o snapshot fica no mesmo provedor e na mesma conta, ele não protege contra bloqueio de conta ou falha operacional ampla.

Um desenho simples para produção pequena seria: snapshot diário da VPS, pg_dump diário enviado para armazenamento externo, retenção de 7 dias para backups diários e 4 semanas para backups semanais. Para produção mais séria, use pg_basebackup ou ferramenta especializada, arquive WAL e teste restauração em uma VPS separada. O comando de dump precisa ser executado com usuário de permissão adequada, compactado e validado. Um arquivo de 0 byte enviado para o storage não é backup, é uma falsa sensação de segurança.

Teste de restauração precisa entrar na rotina

A rotina de restauração deve ser documentada. Por exemplo: criar VPS limpa, instalar mesma versão major do PostgreSQL, restaurar dump, rodar migrações pendentes em modo controlado e validar contagens de tabelas críticas. Faça isso mensalmente em projeto pequeno e com frequência maior em ambiente crítico. Registre tempo de restauração. Se o banco tem 80 GB e demora 3 horas para voltar, essa informação precisa estar no planejamento. Backup bom é aquele que alguém consegue restaurar sob pressão, sem depender da memória de uma única pessoa.

Segurança da VPS e do PostgreSQL em produção

Segurança em VPS para PostgreSQL começa antes de instalar o banco. O ideal é reduzir superfície de ataque. SSH deve usar chave, não senha, com acesso root direto desabilitado quando possível. O firewall deve liberar apenas portas necessárias. Em muitos cenários, a porta 5432 do PostgreSQL não deve ficar pública. Se a aplicação está na mesma VPS, use conexão local. Se está em outra VPS, prefira rede privada do provedor, VPN ou regra de firewall liberando apenas o IP da aplicação.

Acesso SSH, firewall e portas

Uma configuração básica em Linux inclui atualizar pacotes, criar usuário administrativo, configurar SSH por chave, ativar firewall e instalar ferramentas de monitoramento. Em Ubuntu, equipes costumam usar ufw para liberar portas como 22, 80 e 443, além de restringir 5432. Em ambientes com painel, confira se o painel não abre portas adicionais sem necessidade. Também defina atualização de segurança para pacotes críticos, mas planeje janelas de manutenção para upgrades de versão major do PostgreSQL. Atualizar o sistema é rotina. Atualizar PostgreSQL de 15 para 16 exige cuidado, backup e teste.

Usuários, senhas e permissões no banco

No PostgreSQL, não use o superusuário da instalação para a aplicação. Crie um usuário específico, com senha forte, acesso apenas ao banco necessário e permissões coerentes com o que a aplicação faz. Se existe aplicação de leitura, como dashboard ou BI, crie usuário read only. Isso reduz estrago caso uma credencial vaze. Também revise pg_hba.conf, que controla como clientes se autenticam. Regras amplas, como liberar qualquer IP, são comuns em tutoriais rápidos e perigosas em produção.

Criptografia em trânsito também merece atenção. Para conexões entre servidores, use SSL no PostgreSQL ou túnel seguro quando a rede privada não for suficiente. Guarde segredos fora do repositório Git. Use variáveis de ambiente, secret manager ou mecanismo equivalente do seu deploy. Logs de aplicação não devem imprimir strings de conexão completas. Em incidente real, a diferença entre uma senha vazada e uma senha vazada com acesso restrito por IP pode ser enorme.

Rede, latência e conexão entre aplicação e banco

PostgreSQL é sensível a latência quando a aplicação faz muitas consultas pequenas. Uma única query com 150 ms de latência talvez passe despercebida. Cinquenta queries sequenciais por requisição viram vários segundos. Por isso, a localização da VPS do banco deve ser escolhida junto com a aplicação. Se seus usuários estão no Brasil, um datacenter em São Paulo pode reduzir latência percebida quando a aplicação também está próxima. Se a aplicação roda nos Estados Unidos e o banco no Brasil, a comunicação entre eles pode virar gargalo mesmo com CPU e NVMe sobrando.

Quando manter API e banco na mesma região

A regra prática é manter aplicação e banco na mesma região, e de preferência na mesma rede privada, quando o provedor oferece esse recurso. Em um cenário simples, API e PostgreSQL na mesma VPS reduzem latência e custo, mas aumentam disputa por CPU, RAM e disco. Em um cenário mais maduro, API em uma VPS e banco em outra permitem escalar separadamente. Uma API com 2 vCPUs e 2 GB pode atender tráfego HTTP, enquanto o banco roda em 4 vCPUs e 8 GB. Essa separação também facilita manutenção, porque reiniciar a aplicação não mexe no banco.

Pool de conexões evita gargalos silenciosos

Muitas aplicações abrem conexões demais. PostgreSQL lida bem com conexões, mas cada conexão consome memória. Se uma API cria 200 conexões para um banco em VPS de 4 GB, o problema aparece como lentidão, alto uso de RAM e erros intermitentes. Use pool de conexões na aplicação e considere PgBouncer quando houver muita concorrência. Um pool de 10 a 30 conexões pode atender bastante tráfego se as queries forem rápidas. Ajuste com métricas, não por palpite.

Também observe timeout, retry e transações longas. Uma transação aberta por minutos pode travar vacuum e aumentar bloat. Um retry mal configurado pode multiplicar carga durante instabilidade. Rede boa ajuda, mas disciplina de aplicação ajuda mais. Monitore tempo médio de query, conexões ativas, locks, dead tuples, uso de disco e taxa de checkpoint. Sem métricas, a equipe só descobre o problema quando o cliente reclama.

Comparação prática de perfis de VPS para PostgreSQL

A tabela abaixo não é um ranking de provedores nem comparação de preços. Ela organiza perfis técnicos de VPS para orientar compra, teste e revisão humana antes de qualquer contratação. Recursos como preço, banda, tipo exato de processador, região e política de backup mudam com frequência nos provedores. Confirme tudo no site oficial antes de publicar orçamento ou migrar produção.

Perfil de uso	Configuração inicial sugerida	Quando faz sentido	Pontos de atenção
Homologação e dev solo	1 a 2 vCPUs, 2 GB RAM, 40 GB SSD ou NVMe	Testes, staging, protótipos, bancos pequenos	Não usar como produção crítica, evitar muitos serviços juntos
Produção pequena	2 vCPUs, 4 GB RAM, 80 GB NVMe	API com tráfego moderado, e-commerce pequeno, painel interno	Backup externo, firewall, pool de conexões e monitoramento básico
SaaS ou API em crescimento	4 vCPUs, 8 GB RAM, 160 GB NVMe	Múltiplos clientes, filas, relatórios, importações e jobs	Separar aplicação e banco, testar PITR, acompanhar locks e I/O
Produção crítica	8 vCPUs ou mais, 16 GB RAM ou mais, NVMe com backup robusto	Alto volume, baixa tolerância a perda de dados, receita dependente do banco	Réplica, plano de failover, restauração testada e revisão humana de arquitetura

Na prática, a escolha deve acompanhar maturidade operacional. Um projeto novo pode começar em produção pequena, desde que tenha backup externo e plano de expansão. O erro é contratar o menor plano possível para um banco que guarda pedidos, pagamentos ou dados de clientes. Outra armadilha é aumentar CPU sem corrigir queries ruins. Antes de escalar, rode EXPLAIN ANALYZE nas consultas mais lentas, revise índices, limite conexões e monitore I/O. Se o gargalo for falta de índice, trocar de VPS só adia o problema. Se o gargalo for disco saturado durante commits, NVMe e ajustes de checkpoint podem ter impacto maior.

Recomendações por perfil

Dev solo e projetos pequenos

Para um desenvolvedor solo, a recomendação prática é começar com 2 vCPUs, 4 GB de RAM e 80 GB de NVMe se o projeto já atende usuários reais. Para estudo, staging ou MVP sem dados críticos, 1 a 2 vCPUs e 2 GB podem funcionar, mas com pouca margem. Mantenha PostgreSQL, aplicação e Redis na mesma VPS apenas se o tráfego for baixo. Configure backup diário com pg_dump, envie para armazenamento externo e teste restauração antes de anunciar o serviço ao público. Evite expor a porta 5432 para a internet. Se precisar acessar de casa, use túnel SSH, VPN ou liberação temporária de IP.

Time pequeno com API em produção

Times pequenos que mantêm API, painel administrativo e jobs em background devem separar aplicação e banco assim que o produto ganha tração. Um desenho comum é uma VPS para API com 2 vCPUs e 2 a 4 GB de RAM, e outra para PostgreSQL com 4 vCPUs, 8 GB de RAM e 160 GB de NVMe. Isso reduz disputa por recursos e facilita manutenção. Use pool de conexões, monitore queries lentas e defina alertas para disco acima de 75%, RAM pressionada e conexões próximas do limite. Backup precisa incluir dump, snapshot e teste de restauração. Documente quem pode acessar o banco e como credenciais são rotacionadas.

Produção crítica ou SaaS em crescimento

Para produção crítica, a conversa muda de VPS barata para arquitetura de continuidade. Considere 8 vCPUs ou mais, 16 GB de RAM ou mais, NVMe com boa consistência de I/O, backup externo, PITR, réplica de leitura ou standby e plano de failover. Se o banco sustenta receita, a restauração precisa ser ensaiada. Defina RPO e RTO por escrito. Um SaaS financeiro pode aceitar perder no máximo 5 minutos de dados, enquanto um painel interno talvez aceite 24 horas. Também revise permissões, trilhas de auditoria, criptografia em trânsito e atualização de versão. Nessa etapa, claims de performance e comparativos de preço devem passar por revisão humana e, quando possível, benchmark com metodologia documentada.