Planejamento de Capacidade em Profundidade
O planejamento de capacidade para PostgreSQL é fundamentalmente sobre três recursos, CPU, memória e I/O de disco, mais um teto rígido que se comporta de maneira diferente dos três: o limite de conexão.
//
Busque em todas as páginas da documentação
O planejamento de capacidade para PostgreSQL é fundamentalmente sobre três recursos, CPU, memória e I/O de disco, mais um teto rígido que se comporta de maneira diferente dos três: o limite de conexão.
Esta página constrói o modelo mental que conecta esses recursos aos sintomas que as equipes realmente observam, para que uma decisão de dimensionamento comece a partir de evidências em vez de redimensionar a instância por reflexo.
cache hit ratio), teto de conexão (connection ceiling), escalonamento vertical (vertical scaling), escalonamento horizontal (horizontal scaling), previsão de crescimento (growth forecasting).connection pooling), otimização de desempenho de consultas (query performance tuning), monitoramento e alertas (monitoring and alerting), dimensionamento de plataforma gerenciada (managed platform sizing).A capacidade de CPU governa quanta execução de consulta, ordenação e trabalho de autovacuum o cluster pode realizar simultaneamente.
A capacidade de Memória governa a eficácia do cache através de shared_buffers e do cache de página do sistema operacional, determinando com que frequência uma leitura é atendida pela RAM em vez do disco.
A capacidade de I/O de Disco governa a rapidez com que a camada de armazenamento pode atender leituras que não estão no cache e absorver o fluxo contínuo de escritas WAL que cada transação gera.
O teto de conexão (connection ceiling), definido por max_connections, se comporta de maneira diferente dos outros três, pois é um corte rígido em vez de uma degradação gradual, e uma vez atingido, novas sessões são rejeitadas imediatamente em vez de apenas serem desaceleradas.
Um modelo mental útil é uma cozinha de restaurante: CPU é o número de cozinheiros que podem trabalhar ao mesmo tempo, memória é o espaço no balcão que evita viagens repetidas à geladeira, I/O de disco é a rapidez com que essa geladeira pode ser acessada, e o teto de conexão é o número fixo de comandas que a impressora da cozinha pode fisicamente comportar.
Adicionar cozinheiros não ajuda se a geladeira for o gargalo, e uma geladeira maior não ajuda se a impressora estiver travada, que é exatamente por que o planejamento de capacidade começa identificando qual recurso está realmente restrito.
O PostgreSQL expõe as evidências para esse diagnóstico diretamente através de pg_settings, pg_stat_activity e ferramentas de nível de host como iostat, então os dados necessários para distinguir uma carga de trabalho limitada por CPU de uma limitada por I/O já estão disponíveis em todos os clusters.
Decisões de dimensionamento feitas sem essas evidências tendem a se basear no hábito, redimensionando para uma classe de instância familiar em vez do que o perfil de recurso real da carga de trabalho exige.
Os quatro recursos interagem através de uma cadeia que começa com uma consulta e termina com a conclusão rápida ou latência visível para o usuário.
Uma consulta primeiro compete por CPU para planejar e executar, depois por memória (work_mem) se precisar ordenar ou fazer hash, e finalmente por I/O de disco se os dados de que precisa não estiverem residentes em shared_buffers ou no cache do SO.
effective_cache_size não aloca memória por si só; ele informa ao planejador de consultas aproximadamente quanta cache está disponível em todo o sistema, o que molda a escolha do plano, como favorecer um index scan em vez de um sequential scan quando o planejador espera que as páginas relevantes já estejam em cache.
Sob carga de escrita sustentada, I/O de disco e CPU interagem através do autovacuum, pois uma tabela que gera tuplas mortas mais rápido do que o autovacuum pode recuperá-las causa tanto inchaço de índices (mais I/O por varredura) quanto mais CPU gasta avaliando linhas que eventualmente serão descartadas.
-- Um mecanismo concretizado: este sinal distingue
-- "consultas estão em execução" de "consultas estão em fila", o que
-- é a primeira bifurcação em qualquer diagnóstico de capacidade.
SELECT count(*) FILTER (WHERE state = 'active') AS active,
count(*) FILTER (WHERE wait_event_type = 'Lock') AS blocked,
count(*) AS total
FROM pg_stat_activity
WHERE backend_type = 'client backend';As conexões interagem com todos os três recursos indiretamente, mas significativamente, pois cada backend aberto consome memória mesmo quando ocioso, e uma tempestade de conexões de uma aplicação com pool insuficiente pode esgotar max_connections muito antes que a CPU ou o disco mostrem qualquer tensão real.
Um erro comum de raciocínio é dimensionar a CPU ou o tamanho da instância primeiro, quando o gargalo real é frequentemente um índice ausente ou uma contagem de conexão ilimitada, ambos que uma instância maior não corrigirá e apenas tornará mais caro continuar ignorando.
Em escala, o planejamento de capacidade muda de combate reativo a incêndios para uma disciplina de previsão que antecipa o esgotamento de recursos antes que se torne um incidente.
O crescimento do armazenamento é o recurso que a maioria das equipes subestima, pois o crescimento de tabelas e índices se compõe com cargas de trabalho de séries temporais ou logs de eventos de uma forma que um único snapshot pontual não revela, tornando a projeção baseada em tendências mais útil do que um alerta estático de "porcentagem livre".
A escolha entre escalonamento vertical, réplicas de leitura e estratégias horizontais como particionamento ou sharding depende de qual recurso está realmente restrito: uma carga de trabalho de escritor único limitada por CPU ou memória se beneficia do escalonamento vertical, uma carga de relatório com muitas leituras se beneficia de réplicas, e uma única tabela muito grande para ser desfragmentada ou indexada eficientemente se beneficia do particionamento, independentemente do tamanho da instância.
O sharding especificamente deve ser tratado como último recurso nesta hierarquia, pois introduz complexidade de consulta entre shards e sobrecarga operacional que o particionamento ou as réplicas de leitura geralmente evitam, enquanto resolvem a mesma pressão subjacente.
O pool de conexões interage com o planejamento de capacidade em um nível arquitetônico, pois um pooler como o PgBouncer muda o recurso real que está sendo dimensionado de "conexões por instância de aplicação" para "conexões por pool", o que é o que torna os tiers de aplicação escalados horizontalmente (muitos pods, muitas invocações serverless) compatíveis com um teto fixo de max_connections.
Revisões de capacidade realizadas em cadência trimestral, correlacionando crescimento de tabelas, picos de conexão e custo das principais consultas, detectam a lenta deriva em direção a um teto de recursos muito antes que se torne um alerta às 3 da manhã.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Escalonamento vertical (instância maior) | Simples, sem alterações na aplicação | O custo cresce mais rápido que linearmente no topo, tem um teto | Cargas de trabalho de escritor único limitadas por CPU ou memória |
| Réplicas de leitura | Descarrega tráfego de leitura, melhora a latência de leitura | Atraso de replicação (replication lag), não ajuda na taxa de transferência de escrita | Carga de relatórios ou análise com muitas leituras |
| Particionamento | Limita o custo de manutenção de vacuum e índice por partição | A complexidade de consulta e migração aumenta | Tabelas únicas muito grandes com uma chave natural (tempo, tenant) |
| Sharding | Distribui carga de leitura e escrita horizontalmente | Consultas entre shards, sobrecarga operacional significativa | Taxa de transferência de escrita que excede qualquer primário único, último recurso |
lock-bound), então a CPU pode parecer saudável enquanto as consultas ficam em fila atrás de esperas de disco ou transações bloqueantes.max_connections deve ser definido alto 'para crescimento'." - cada conexão aberta consome memória, esteja ociosa ou ativa, então um teto alto sem pooling arrisca esgotamento de memória, não margem.shared_buffers maior sempre significa melhor taxa de acerto de cache." - os retornos diminuem bem antes de 100% da RAM, e o cache de página do SO faz um trabalho significativo que shared_buffers superdimensionado pode ofuscar.CPU para execução de consultas, memória para cache, I/O de disco para leituras e escritas WAL, e o teto de conexão como um limite rígido distinto.
O PostgreSQL é frequentemente limitado por I/O de disco ou contenção de bloqueio, ambos os quais podem saturar independentemente da CPU.
Ele não aloca memória por si só; ele informa a estimativa do planejador de consultas de cache disponível, o que influencia a escolha do plano, como indexação versus varreduras sequenciais.
É um corte rígido em vez de uma degradação gradual, rejeitando novas sessões imediatamente quando max_connections é atingido, em vez de apenas desacelerá-las.
Uma tabela que acumula tuplas mortas mais rápido do que o autovacuum pode recuperá-las causa índices inchados que custam mais I/O por varredura e mais CPU avaliando linhas descartáveis.
O escalonamento vertical se encaixa em cargas de trabalho de escritor único limitadas por CPU ou memória, enquanto uma réplica de leitura se encaixa em tráfego de relatórios com muitas leituras que não afeta o gargalo de escrita.
Ele introduz complexidade de consulta entre shards e sobrecarga operacional que particionamento ou réplicas de leitura geralmente evitam, enquanto aborda a mesma pressão subjacente.
Ele muda o recurso que está sendo dimensionado de conexões por instância de aplicação para conexões por pool, permitindo que um tier de aplicação escalado horizontalmente permaneça sob um teto fixo de max_connections.
Um único snapshot pontual não revela o crescimento composto de cargas de trabalho de séries temporais ou logs de eventos, então a projeção baseada em tendências captura o que uma verificação estática de espaço livre perde.
Não, a carga de trabalho e o volume de dados mudam continuamente, então uma cadência de revisão trimestral é necessária para capturar a deriva antes que ela se torne um incidente.
Raramente; um índice ausente ou um plano de consulta ruim geralmente dominam o tamanho bruto da instância, e dimensionar o hardware primeiro muitas vezes apenas torna a mesma ineficiência mais cara.
Eventos de espera do pg_stat_activity, taxa de acerto de cache, métricas de I/O de nível de host e saturação de conexão, para que a decisão vise o recurso que está realmente restrito.
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (major 18 estável, linha de manutenção 17) e PgBouncer 1.x.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026