¿Qué es el pooling de conexiones y por qué una base de datos se satura?
Publicado el 2026-10-26 por frfrand
Pooling de conexiones explicado: cómo reutilizar conexiones, límites, colas y PgBouncer.
Un pool de conexiones es un conjunto reutilizable de conexiones a una base de datos. Reduce el coste de abrir y cerrar sesiones continuamente y permite controlar cuántas conexiones simultáneas recibe el servidor.
Una forma sencilla de entenderlo
Imaginá una empresa donde cada visitante necesita una mesa de atención. Construir una mesa nueva para cada persona sería absurdo: resulta mejor mantener un número razonable de mesas disponibles y asignarlas a medida que llegan solicitudes.
¿Cómo funciona en la práctica?
La aplicación o un componente intermedio mantiene conexiones que pueden volver a utilizarse. Herramientas como PgBouncer para PostgreSQL ofrecen diferentes modalidades de pooling. El tamaño del pool debe ajustarse a la carga y a los recursos del servidor; cien procesos con veinte conexiones cada uno podrían superar lo que la base admite.
Lo que no resuelve y sus límites
Un pool no hace más rápida una consulta mal diseñada ni evita bloqueos. Si está lleno, las solicitudes pueden esperar y agotar sus tiempos de espera. Además, ciertas funciones ligadas a la sesión necesitan atención especial cuando se utiliza pooling por transacción, porque una solicitud puede recibir una conexión física distinta.
Cómo aplicarlo y comprobarlo sin sorpresas
Revisá conexiones activas, tiempos de espera, carga de consultas y parámetros máximos de PostgreSQL. No aumentes el pool indefinidamente: más conexiones pueden aumentar consumo de memoria y empeorar el rendimiento. Probá qué ocurre durante reinicios y fallos de red.
¿Cómo aparece en ArduMaker?
En proyectos con PostgreSQL y backends alojados sobre VPS de ArduMaker, un pool bien dimensionado puede ayudar a manejar tráfico concurrente. Su configuración depende del número de workers y de las necesidades de cada aplicación.
Por qué demasiadas conexiones empeoran una aplicación
Cada conexión activa utiliza recursos del motor, aunque no esté ejecutando una consulta todo el tiempo. Una flota de workers que abre decenas de conexiones cada uno puede agotar el límite disponible incluso con CPU relativamente baja. El pool permite coordinar ese uso, pero si todas las operaciones bloquean durante demasiado tiempo seguirá habiendo esperas.
Un detalle de producción
Las migraciones de esquema y las conexiones de larga duración pueden necesitar un comportamiento distinto del tráfico normal. Antes de introducir PgBouncer, verificá compatibilidad con transacciones, prepared statements y estado de sesión según tu cliente y modalidad elegida. Probá bajo concurrencia real y revisá los tiempos de espera.
¿Cómo calcular un punto de partida?
Contá las conexiones abiertas en la base de datos durante una hora habitual y un pico. Compará esa cifra con los procesos que ejecutan consultas, la duración de las transacciones y los límites del servidor. Un pool demasiado pequeño provoca esperas; uno demasiado grande puede agotar memoria y aumentar la competencia. Elegí una configuración inicial medible y revisala con carga real.
Para recordar
Un pool de conexiones es un conjunto reutilizable de conexiones a una base de datos. Entender cuándo se aplica, cómo falla y qué datos revisar es más útil que memorizar comandos sueltos.
Para ampliar: PgBouncer: características y configuración.