Busca en todas las páginas de la documentación
La planificación de capacidad mantiene PostgreSQL por delante del crecimiento del tráfico, disco y conexiones. Revise trimestralmente con exportaciones frescas de pg_stat_statements y tamaño de tabla, no por intuición.
pg_stat_statements por total_exec_time semanalmente. Detección de regresiones.max_connections en un gráfico. Incluir conexiones del servidor PgBouncer.pg_total_relation_size.iowait en el host. Valida el dimensionamiento de RAM/disco.EXPLAIN en las 3 principales consultas. Indexar o reescribir primero.n_dead_tup no aumenta sin límite.idx_scan = 0 durante más de 30 días.30-60 minutos con panel de pre-lectura; elementos de acción asignados antes del final.
SRE de plataforma mantiene; producto proporciona supuestos de crecimiento.
SKU más pequeño está bien; coincidir con la versión principal y el conjunto de extensiones; el cálculo de conexiones todavía se enseña.
Disco > 90% o conexiones > 90% - cambio vertical inmediato; postmortem actualiza el pronóstico.
Redimensionar hacia abajo en un trimestre tranquilo solo con prueba de métricas, no por mandato financiero.
El autoscale de cómputo de Neon todavía necesita pronósticos de conexión y almacenamiento.
Evitar para planes de capacidad OLTP de producción - usar clase de rendimiento fijo.
Almacenar resultados de pgbench o k6 por versión en staging en un SKU fijo.
Etiquetar instancias; imputar el crecimiento del almacenamiento al centro de costos del servicio.
El líder técnico reconoce la revisión en el ticket; ADR si se cruza el umbral de partición.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.
Revisado por Chris St. John·Última actualización: 19 jul 2026