Busque em todas as páginas da documentação
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.
pg_stat_statements por total_exec_time exportado semanalmente. Detecção de regressão.max_connections plotada. Inclua conexões do servidor PgBouncer.pg_total_relation_size.iowait no host. Valida o dimensionamento de RAM/disco.EXPLAIN nas 3 principais consultas. Indexar ou reescrever primeiro.n_dead_tup não crescendo sem limites.idx_scan = 0 em mais de 30 dias revisado.30-60 minutos com painel de pré-leitura; itens de ação atribuídos antes do final.
SRE da plataforma mantém; produto fornece suposições de crescimento.
SKU menor OK; corresponda à versão principal e ao conjunto de extensões; cálculo de conexões ainda ensinado.
Disco > 90% ou conexões > 90% - mudança vertical imediata; postmortem atualiza a previsão.
Redimensione para baixo em um trimestre tranquilo apenas com prova de métricas, não por mandato financeiro.
O autoscale de computação Neon ainda precisa de previsões de conexão e armazenamento.
Evite para planos de capacidade OLTP de produção - use classe de desempenho fixa.
Armazene resultados de pgbench ou k6 por versão em staging em SKU fixo.
Marque instâncias; cobre o crescimento do armazenamento no centro de custo do serviço.
Líder técnico reconhece a revisão no ticket; ADR se cruzar o limite de shard.
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+.
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026