PgBouncer 1.25 frente a conexiones directas: costo y límite
Cuándo poner PgBouncer delante de PostgreSQL: pool por transacción, límites, permisos, monitoreo, backup y prueba de saturación antes de producción.
Cien usuarios web no necesitan cien conexiones abiertas a PostgreSQL durante todo el día hábil. En un colegio profesional de Cuyo, la inscripción a cursos llenaba el pool de la aplicación cada vez que vencía una matrícula. PgBouncer 1.25 entra delante de la base para ordenar espera, reutilización y límite; esta guía explica qué resuelve, qué rompe y cómo probarlo.
Dónde aparece el costo de cada conexión
PostgreSQL atiende cada conexión con recursos propios del servidor. La documentación de PostgreSQL 17 advierte que ciertos recursos se dimensionan directamente con max_connections. Esa frase se siente abstracta hasta que una pyme sube el límite para apagar un incendio y descubre que la memoria quedó más justa que antes.
La cifra que corrige la costumbre viene de la adopción. Stack Overflow 2024 registró PostgreSQL con 48,7% de uso entre desarrolladores. Cuando una base tan común recibe más aplicaciones web, reportes, integraciones y jobs, el cuello de botella rara vez aparece por una sola consulta: aparece por conexiones ociosas que ocupan lugar.
PgBouncer publicó la versión 1.25.2 el 8 de mayo de 2026. El dato de versión importa porque varias pymes instalan el paquete del sistema operativo y nunca vuelven a mirar el pooler. La mejora técnica no sirve si el servicio queda viejo, sin métricas y sin una prueba de caída.
El antagonista es el botón de “subir max_connections”. Parece una salida corta: se aumenta de 100 a 300 y la aplicación vuelve. El costo llega después, cuando cada proceso reserva memoria, los backups compiten por disco y un reporte largo deja esperando a operaciones normales.
El objeto que delata el problema es el listado impreso de matrículas vencidas, con marcas de resaltador y horario de cobro. Cada fila espera una consulta corta, pero todas llegan juntas después del aviso masivo.
Cómo funciona por dentro
El flujo empieza en la aplicación. El usuario carga una cuota, una factura o una búsqueda. La aplicación pide conexión a PgBouncer en vez de abrir una sesión directa contra PostgreSQL. PgBouncer recibe muchas conexiones de cliente y mantiene menos conexiones reales hacia la base, según pool_mode, default_pool_size y límites por base o usuario.
En modo transacción, cuando la transacción termina, la conexión de servidor vuelve al pool. En modo sesión, queda asociada al cliente hasta que corta. La tabla de funciones compatibles obliga a revisar prepared statements, variables de sesión y operaciones que dependen de una conexión persistente. Esa revisión evita una falla silenciosa.
PostgreSQL guarda registros estructurados: cuotas, pagos, cursos, usuarios y auditoría. PgBouncer no guarda datos de negocio; administra espera, reutilización y límites. La aplicación sigue autenticando usuarios finales con su sistema habitual. PgBouncer autentica conexiones técnicas y entrega estadísticas de pools, clientes, servidores y colas.
Los permisos separan capas. Desarrollo puede cambiar cadena de conexión en la aplicación. Sistemas administra pgbouncer.ini, usuarios técnicos y servicio. Administración solo ve tableros de cola y tiempos, porque editar el pool no es una tarea contable. El backup sigue apuntando a PostgreSQL; la prueba de restauración valida base y configuración de PgBouncer en otro host.
Qué se instala o configura primero
La pila mínima usa PostgreSQL 17 o 18, PgBouncer 1.25, métricas del proceso, logs de conexión y una prueba de carga simple. En un servidor chico, PgBouncer puede correr en la misma red que la base o en el host de aplicación. El costo mensual adicional ronda USD 8 a 20, entre ARS 11.456 y ARS 28.640 al dólar vendedor de ARS 1.432, si se aprovecha infraestructura existente. El cálculo no incluye diagnóstico de consultas lentas.
El primer entregable verificable es una prueba con 150 clientes concurrentes y una base limitada a 30 conexiones reales. La aplicación debe completar operaciones normales, mostrar cola controlada y registrar rechazos cuando se supere el límite pactado. UMSA suele pedir dos capturas: una antes con conexiones directas y otra después con PgBouncer, para que la decisión se vea en números.
La configuración inicial define pool_mode, max_client_conn, default_pool_size, usuarios técnicos, archivo de credenciales y un puerto separado. Después se cambia una sola aplicación. Recién cuando esa prueba pasa se suman reportes, jobs y paneles.
Dónde se rompe y cómo probarlo
El primer riesgo es elegir el modo equivocado. La señal aparece cuando una función depende de estado de sesión y falla al terminar la transacción. La prueba ejecuta las operaciones más usadas con pool_mode=transaction y revisa errores antes de producción.
El segundo riesgo es esconder consultas lentas. La señal es una cola creciente aunque la cantidad de conexiones reales esté bajo control. La prueba corre EXPLAIN sobre las consultas más lentas y mide espera en PgBouncer junto con tiempo en PostgreSQL.
El tercer riesgo es perder acceso administrativo. La señal aparece cuando nadie puede entrar al panel de PgBouncer durante una saturación. La prueba documenta usuario, comando SHOW POOLS, ruta del servicio y reinicio controlado.
El pool no arregla una consulta mala; muestra con más precisión cuándo la base está ocupada.