Quanta CPU e RAM o PostgreSQL precisa em um VPS com vCPU dedicado?

Quantas vCPU o PostgreSQL usa?

O PostgreSQL usa uma thread de CPU por consulta em execução, porque cada conexão recebe seu próprio processo backend. A documentação chama isso de modelo "process per user": o postmaster cria um novo backend para cada conexão. A CPU de que um banco de dados precisa é, portanto, definida pelo número de consultas executando no mesmo instante, não pelo número de conexões abertas. Uma conexão ociosa custa memória e nenhuma CPU.

Três coisas somam threads além das suas consultas:

• Consulta paralela. Um scan grande recruta ajudantes: max_parallel_workers_per_gather tem padrão 2 e max_parallel_workers tem padrão 8, retirados de max_worker_processes (padrão 8).
• Autovacuum. Até autovacuum_max_workers processos (padrão 3) limpam tabelas em segundo plano.
• A aplicação, quando roda na mesma VPS.

Em uma VPS de 2 vCPU, um relatório que entra em modo paralelo pode ocupar todas as threads enquanto as consultas curtas do app esperam atrás dele. Reduzir max_parallel_workers_per_gather para a role de relatórios, ou subir um plano, resolve. A regra de thread versus núcleo por trás dessas contagens está explicada em uma vCPU dedicada é um núcleo ou uma thread.

Quanta RAM o PostgreSQL precisa em uma VPS?

Comece com shared_buffers em 25% da RAM da VPS e deixe a maior parte do restante para o page cache do sistema operacional. A documentação do PostgreSQL 18 indica esse valor inicial para um servidor de banco de dados dedicado com 1 GB ou mais de RAM e acrescenta que mais de 40% provavelmente não funciona melhor, porque o PostgreSQL também conta com o cache do kernel. O padrão de fábrica é 128 MB.

Mais duas configurações decorrem da RAM:

• effective_cache_size é só uma estimativa para o planner (padrão 4 GB). Defina com o que shared_buffers e o page cache guardam juntos, para que os index scans tenham custo correto.
• work_mem (padrão 4 MB) vale para cada etapa de sort ou hash em cada sessão. Uma consulta complexa a usa várias vezes, e muitas sessões fazem isso ao mesmo tempo, então aumente com cuidado.

Segundo o levantamento da Cobaltfell de 2 de novembro de 2026, 106 dos 202 planos com CPU dedicada registrados em provedores que aceitam cripto sem checagem de identidade ofereciam 4 GB de RAM ou mais por vCPU. Para um banco de dados, RAM por vCPU importa tanto quanto a quantidade de vCPU.

Os planos por trás dessa contagem estão listados em quanto custa uma VPS com CPU dedicada por núcleo em novembro de 2026.

Como o CPU steal afeta a latência p99 do PostgreSQL?

O CPU steal alonga o 1% mais lento das consultas muito antes de mexer na média. O kernel Linux descreve steal como espera involuntária: tempo em que uma vCPU tinha trabalho enquanto o hypervisor executava outra pessoa. Um backend pausado no meio de uma consulta simplesmente para, e todo cliente esperando por essa consulta, ou por um lock que ela mantém, para junto.

As pausas são curtas e irregulares, então atingem só as consultas que estiverem na CPU naquele momento. Como ilustração, não medição: quando uma vCPU perde algumas dezenas de milissegundos para um vizinho de vez em quando, uma consulta de 2 ms que cai em uma dessas janelas leva dez vezes mais, enquanto as milhares de consultas ao redor rodam em velocidade normal. A média quase não muda; o percentil 99 carrega todo o custo.

Um banco de dados em uma vCPU compartilhada, portanto, parece saudável nas médias e ainda assim gera timeouts. Três leituras expõem isso:

• Steal: a coluna %steal do mpstat na hora de maior movimento, explicada em o que é o tempo de CPU steal e como verificá-lo em uma VPS.
• Piores casos: pg_stat_statements reporta max_exec_time e stddev_exec_time por statement, e nenhum percentil.
• Percentis: log_min_duration_statement (por exemplo 250ms) registra statements lentos; um histograma de latência na aplicação fornece o próprio p99.

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

O que uma vCPU dedicada muda para um banco de dados?

Uma vCPU dedicada elimina a única fonte de cauda de latência que não dá para ajustar de dentro da VPS. Planos lentos, índices faltando e contenção de lock são responsabilidade do operador; o job em lote de um vizinho em um núcleo compartilhado não é. O caso geral está em qual é a diferença entre uma vCPU compartilhada e uma dedicada. Em uma VPS Cobaltfell:

• CPU: Uma vCPU é um thread de hardware do processador do host. As suas são fixadas uma a uma ao seu VPS e nunca são emprestadas a outro cliente, e os dois threads de um núcleo físico ficam juntos, então cada 2 vCPU formam um núcleo inteiro que nenhum vizinho compartilha.
• Steal: Em uma vCPU dedicada, o steal time deve ficar em ou perto de zero. Vamos publicar o número que medimos nas nossas próprias máquinas, com a data, e nunca uma estimativa.
• Memória: A RAM do seu plano é reservada para o seu VPS e não é overcommitted.
• Disco: Armazenamento NVMe em todos os planos.
• Carga: Carga total é permitida pelo tempo que o seu trabalho precisar: sem créditos de CPU, sem janela de burst e sem throttling depois de alguns minutos a 100%. Um VACUUM longo ou uma criação de índice roda a pleno vapor.

A família do processador é AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Quando uma VPS é o lugar errado para o PostgreSQL?

Uma VPS é o lugar errado quando os dados consultados a cada minuto são muito maiores que a RAM do maior plano, ou quando réplicas e backups precisam ser gerenciados para você. O Fell 16 tem 32 GB. Um working set que não cabe na memória transforma toda consulta em leitura de disco, e aí a vazão de armazenamento, e não a vCPU, define o ritmo.

Os backups ficam com o operador: Backups não fazem parte de nenhum plano: mantenha uma cópia dos seus dados em outro lugar. Um pg_dump noturno ou um arquivo WAL enviado para armazenamento em outro lugar cobre a maioria dos bancos de dados pequenos; um teste de restore pertence à agenda antes de ser necessário.

Failover entre duas ou três VPS com streaming replication funciona, mas é autogerenciado. A Cobaltfell vende os servidores, não um banco de dados gerenciado. Os preços de cada tamanho estão em quanto custa uma VPS com núcleos dedicados.