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

> Quanta CPU e RAM o PostgreSQL precisa em um VPS? Um vCPU dedicado por consulta ativa, shared_buffers em 25% da RAM, 2 a 16 vCPU. Cripto, sem KYC.

- URL: https://cobaltfell.com/pt/vps-for-postgresql/
- Última atualização: 2026-11-02
- Editor: Cobaltfell (https://cobaltfell.com)

Quanta CPU e RAM o PostgreSQL precisa em uma VPS? Como o PostgreSQL transforma conexões em trabalho de CPU, o que a documentação do PostgreSQL 18 diz sobre memória, qual plano serve para qual banco de dados e por que o CPU steal aparece primeiro nas consultas mais lentas.

**Resposta rápida — Quanta CPU e RAM o PostgreSQL precisa em uma VPS?**

O PostgreSQL precisa de cerca de uma vCPU por consulta em execução no mesmo instante e de RAM suficiente para manter seu working set em cache. Na **Cobaltfell**, o Fell 2 (4 GB) atende um app de produção pequeno, e o Fell 8 (16 GB) atende um banco de dados que roda relatórios junto com o tráfego ao vivo. A documentação do PostgreSQL 18, consultada em 2 de novembro de 2026, indica 25% da RAM como valor inicial para shared_buffers.

## 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](https://cobaltfell.com/pt/vcpu-vs-core/ "Um vCPU dedicado é um núcleo ou uma thread em um VPS?").

## 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](https://cobaltfell.com/pt/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*shared_buffers = 25% da RAM do plano, o valor inicial na documentação do PostgreSQL 18. A coluna "Serve para" é um ponto de partida, não uma medição: Os nossos próprios resultados do YABS e do Geekbench 6, junto com o steal time que medimos, serão publicados com a data assim que a nossa primeira máquina de teste for entregue. Até lá, não divulgamos nenhum número de desempenho nosso.*

| Plano | vCPU | RAM | shared_buffers em 25% | Cabe |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | O banco de dados de um app, com poucas conexões ocupadas por vez |
| Fell 4 | 4 | 8 GB | 2 GB | Um backend SaaS com tráfego constante, ou um banco de dados mais sua aplicação |
| Fell 8 | 8 | 16 GB | 4 GB | Tráfego ao vivo mais relatórios ou scans paralelos |
| Fell 16 | 16 | 32 GB | 8 GB | Muitas consultas simultâneas e um working set de dezenas de gigabytes |

## 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](https://cobaltfell.com/pt/cpu-steal-time/ "O que é CPU steal time e como verificá-lo na minha 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.

*Conte as consultas ativas, encontre os piores casos, acompanhe o steal*

```bash
# 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](https://cobaltfell.com/pt/dedicated-vs-shared-vcpu/ "Qual é a diferença entre uma vCPU compartilhada e uma vCPU dedicada em um VPS?"). 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](https://cobaltfell.com/pt/pricing/ "Quanto custa um VPS com vCPU dedicada?").

## Que outras perguntas as pessoas fazem sobre PostgreSQL em uma VPS?

### 2 vCPU basta para o PostgreSQL?

Para uma aplicação com um número modesto de conexões ocupadas, sim. Duas vCPU executam duas consultas ao mesmo tempo; uma terceira espera por uma thread livre. O Fell 4 é o próximo passo quando `pg_stat_activity` frequentemente mostra mais consultas ativas que vCPU, ou quando o app divide a VPS.

### O app e o banco de dados devem dividir uma VPS?

No Fell 2 e no Fell 4 é comum e economiza um salto de rede. Os processos ocupados do app contam como usuários extras de vCPU. Separe-os quando deploys ou picos de tráfego começarem a aparecer no log de consultas lentas do banco de dados.

### O PostgreSQL em uma VPS precisa de um connection pooler?

Na maioria das aplicações web, sim. `max_connections` tem padrão 100, e cada conexão é um processo inteiro ocupando memória. Um pooler como o PgBouncer mantém o número de backends ativos próximo da quantidade de vCPU enquanto o app abre quantas conexões de cliente precisar.

### O que configurar primeiro após instalar o PostgreSQL?

shared_buffers em 25% da RAM, effective_cache_size com a memória que shared_buffers e o page cache guardam juntos, e `log_min_duration_statement` para que consultas lentas deixem rastro. work_mem fica perto do padrão até que um plano lento mostre um sort transbordando para o disco.

### Os backups estão incluídos em uma VPS Cobaltfell?

Não. Backups não fazem parte de nenhum plano: mantenha uma cópia dos seus dados em outro lugar.

## Fontes

1. [PostgreSQL 18: Consumo de recursos (shared_buffers, work_mem, worker processes)](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: Planejamento de consultas (effective_cache_size)](https://www.postgresql.org/docs/current/runtime-config-query.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
3. [PostgreSQL 18: Conexões e autenticação (max_connections)](https://www.postgresql.org/docs/current/runtime-config-connection.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
4. [PostgreSQL 18: Vacuum (autovacuum_max_workers)](https://www.postgresql.org/docs/current/runtime-config-vacuum.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
5. [PostgreSQL 18: Relatórios de erros e logging (log_min_duration_statement)](https://www.postgresql.org/docs/current/runtime-config-logging.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
6. [PostgreSQL 18: Como as conexões são estabelecidas](https://www.postgresql.org/docs/current/connect-estab.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
7. [PostgreSQL 18: pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
8. [O sistema de arquivos /proc: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [página de manual do mpstat(1) (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: A Cobaltfell é uma provedora de VPS com núcleos vCPU dedicados, paga em cripto, sem envio de documento de identidade e operada pela DomaineGoat LLC, empresa registrada no Panamá. Cada vCPU é fixado exclusivamente no seu servidor, em processadores AMD EPYC 9004/9005 (Zen 4 / Zen 5) com armazenamento NVMe, em Amsterdã (Países Baixos), Zurique (Suíça) e Bucareste (Romênia). No período de 12 meses, cada plano tem preço pelo menos 25% abaixo de um plano comparável de CPU dedicada nomeado, escolhido entre 6 provedores de VPS com cripto e sem KYC e consultado em 2 de novembro de 2026.