Melhores Práticas de Planejamento de Capacidade
O planejamento de capacidade mantém o PostgreSQL à frente do crescimento de tráfego, disco e conexões. Revise trimestralmente com exportações recentes de pg_stat_statements e tamanho de tabela, não por intuição.
Como Usar Esta Lista
- Agende revisões recorrentes com o proprietário da plataforma + serviço
- Atualize os números após cada lançamento importante de produto ou mudança de HPA
- Combine com a planilha Previsão de Crescimento de Armazenamento
A - Medição
- Top 20
pg_stat_statementsportotal_exec_timeexportado semanalmente. Detecção de regressão. - Contagem máxima de conexões vs
max_connectionsplotada. Inclua conexões do servidor PgBouncer. - Tamanhos de tabela + índices top 15 mensalmente.
pg_total_relation_size. - Taxa de acerto de cache e
iowaitno host. Valida o dimensionamento de RAM/disco. - Latência de replicação p95 registrada. Decisões de roteamento de leitura.
B - Primeiro Consulta e Esquema
- Sem escala de hardware sem
EXPLAINnas 3 principais consultas. Indexar ou reescrever primeiro. - Autovacuum saudável nas maiores tabelas.
n_dead_tupnão crescendo sem limites. - Particionamento avaliado antes de shard. Caminhos de séries temporais e arquivamento.
- Índices não utilizados removidos.
idx_scan = 0em mais de 30 dias revisado. - Política de arquivamento para dados antigos. Exclusão de partição ou armazenamento frio.
C - Ações de Escala
- Escala vertical documentada com métricas antes/depois. CPU, p95, taxa de acerto de cache.
- Réplicas de leitura apenas para SLO de leitura pesada não atendido. Não um band-aid para escrita.
- Cálculo de pool do PgBouncer atualizado quando a contagem de pods muda. Veja o cálculo de conexões.
- Capacidade máxima de autoscale de disco definida. Alerta 85% de alocação.
- Nível de IOPS aumentado em métricas sustentadas de gargalo de escrita.
D - Planejamento e Governança
- Previsão de armazenamento de 90 dias em ticket/planilha financeira. Inclui backups.
- Reunião trimestral de revisão de capacidade de 30 minutos. Participantes: TL, plataforma, DBA.
- Sharding requer ADR com evidência de 30 dias. Política de último recurso.
- Teste de carga antes da Black Friday / lançamento. k6 ou pgbench com SQL moldado em produção.
- Instâncias reservadas / descontos de compromisso alinhados à previsão. Evite compras de pânico.
E - Risco
- Inventário de slots de replicação mensalmente. Exclua os obsoletos; retenção de WAL limitada.
- Simulação de failover não assume headroom infinito pós-failover. Classe de standby menor revisada.
- Multiplicador de crescimento multi-tenant na previsão. 2x usuários != 2x linhas linearmente - meça.
- Tamanho de restauração de DR cabe no disco de destino de restauração. Não apenas alocação primária.
- Limite de "escala máxima antes da re-arquitetura" documentado. Discute divisão de shard/serviço.
FAQs
Qual a duração da revisão trimestral?
30-60 minutos com painel de pré-leitura; itens de ação atribuídos antes do final.
Quem é o proprietário da planilha?
SRE da plataforma mantém; produto fornece suposições de crescimento.
Dimensionamento do ambiente de desenvolvimento?
SKU menor OK; corresponda à versão principal e ao conjunto de extensões; cálculo de conexões ainda ensinado.
Quando escala de emergência?
Disco > 90% ou conexões > 90% - mudança vertical imediata; postmortem atualiza a previsão.
Otimização de custo vs capacidade?
Redimensione para baixo em um trimestre tranquilo apenas com prova de métricas, não por mandato financeiro.
Incluir serverless?
O autoscale de computação Neon ainda precisa de previsões de conexão e armazenamento.
Instâncias de crédito de CPU?
Evite para planos de capacidade OLTP de produção - use classe de desempenho fixa.
Linha de base de benchmark?
Armazene resultados de pgbench ou k6 por versão em staging em SKU fixo.
Alinhar com FinOps?
Marque instâncias; cobre o crescimento do armazenamento no centro de custo do serviço.
Aprovação?
Líder técnico reconhece a revisão no ticket; ADR se cruzar o limite de shard.
Relacionados
- Noções Básicas de Capacidade - CPU/RAM/disco
- Cálculo de Conexões - aritmética de pool
- Previsão de Crescimento de Armazenamento - modelo de disco
- Escala Vertical vs. Escala Horizontal - escada de escala
- Melhores Práticas de Monitoramento - alinhamento de alertas
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.