¿Cuántas conexiones poner en el pool de base de datos?🌎

Según HikariCP y los tests de PostgreSQL wiki: pool = cores × 2 para carga estándar OLTP. Con SSD, el factor de discos es 1, por lo que la regla práctica queda en cores × 2. Un servidor de 8 cores debería tener pool de ~16 conexiones por aplicación, no 100.

Postgres usa un proceso OS por conexión. Con 8 cores, 50 conexiones simultáneas causan context switching costoso, contención en shared_buffers y esperas en WAL. Los benchmarks muestran que 10–16 conexiones dan más TPS que 50 en un servidor de 8 cores.

Cuando el total de conexiones activas supera cores × 4, o cuando tenés workloads serverless (Lambda, Cloud Run) que pueden abrir cientos de conexiones. PgBouncer en modo transaction reduce 10–100× las conexiones reales a la DB.

connectTimeout: 5–10 s (no bloquear en arranque). socketTimeout/queryTimeout: 30–60 s. idleTimeout: 10 min (libera slots inútiles). maxLifetime: 30 min (fuerza reciclado para evitar leaks de conexión).

RDS Proxy es managed por AWS, ideal para Lambda + Aurora, con costo por hora. PgBouncer es self-hosted, gratis, más control. Para arquitecturas serverless en AWS, RDS Proxy. Para ECS/EKS con control sobre la infra, PgBouncer en modo transaction.

Node.js es single-threaded: un pool de 5–15 conexiones por proceso es habitual. Java con 200 threads de Tomcat podría abrir 200 conexiones (pésimo), por eso HikariCP recomienda 10–20 independientemente del thread count. La regla es dimensionar por cores de DB, no por threads de app.

max_connections default = 100, cada una consume ~10 MB de RAM. Subir a 500 es posible pero a partir de 200–300 simultáneas el rendimiento cae notablemente sin PgBouncer. Arriba de 500 clientes, PgBouncer transaction mode es casi obligatorio.

Sí: minIdle > 0 evita la latencia de abrir conexión al primer request (5–50 ms de TLS+auth). Para APIs latency-sensitive, minIdle = 20–30% del max. Para cargas muy irregulares o funciones serverless, minIdle = 0 y dejás que el pool crezca on-demand.

MySQL InnoDB tolera mejor que Postgres las conexiones altas (usa threads, no procesos), pero la regla cores × 2 sigue siendo un buen punto de partida. SQL Server tiene pooling interno y escala hasta ~1000 conexiones activas antes de degradarse. La calculadora sirve como referencia para cualquier RDBMS.