Cómo dimensionar el pool de conexiones de PostgreSQL

Empieza por el presupuesto del servidor

max_connections no es el tamaño disponible para la aplicación. Reserva sesiones para migraciones, administración, monitorización y recuperación. Después reparte el resto entre todos los servicios, workers y trabajos que usan la instancia. Una API con cuatro réplicas y tres procesos por réplica puede crear doce pools distintos.

PostgreSQL asigna recursos a cada sesión y demasiadas consultas activas compiten entre sí. La documentación oficial sobre conexiones debe leerse junto con la capacidad real de CPU, memoria y disco; subir el límite por sí solo no crea rendimiento.

Calcula el peor caso de despliegue

Multiplica tamaño máximo del pool por procesos por réplicas, y añade workers de cola, tareas programadas, previews y herramientas internas. Usa el máximo durante un rollout, cuando pueden convivir la versión nueva y la anterior. Si el total supera el presupuesto, reduce pools o introduce un proxy de conexiones cuando el patrón lo justifique.

No confundas conexiones abiertas con consultas concurrentes útiles. Para una API que pasa mucho tiempo esperando servicios externos, cientos de peticiones pueden compartir un número menor de sesiones porque solo algunas ejecutan SQL en cada instante.

Mantén transacciones cortas

Abre una transacción justo antes del trabajo de base de datos y ciérrala antes de llamadas HTTP, inferencias o procesamiento largo. Una sesión “idle in transaction” puede retener locks y evitar limpieza de filas antiguas. Configura timeouts para adquisición, consulta y transacción; cada uno responde a una clase distinta de atasco.

Evita iniciar una sesión al comienzo de toda petición si quizá no se utiliza. En trabajos por lotes, procesa bloques y confirma avances recuperables en lugar de mantener una transacción durante miles de registros.

Decide cómo responder cuando no hay capacidad

Esperar indefinidamente traslada la saturación a todos los usuarios. Limita la cola del pool y devuelve un error controlado o aplica backpressure. Los reintentos deben tener variación y un máximo para no crear otra oleada. Una operación no idempotente necesita conocer su resultado antes de repetirse.

Reserva una vía operativa separada para poder diagnosticar el incidente. Si la aplicación consume absolutamente todas las conexiones, incluso consultar actividad o ejecutar una corrección se vuelve difícil.

Ajusta con mediciones de carga

Observa conexiones activas e inactivas, tiempo de espera del pool, duración de transacciones, locks, latencia por consulta y utilización de CPU y disco. Ejecuta una prueba que incluya escalado máximo y despliegue gradual. Aumenta el pool solo si existe espera, la base conserva capacidad y el throughput realmente mejora.

El objetivo no es mantener muchas conexiones, sino completar el trabajo con una cola limitada y margen operativo. Documenta el cálculo junto al autoscaling para que una nueva réplica no convierta automáticamente capacidad web en una caída de PostgreSQL.