Otro pooler para Postgres: por qué importa

Si trabajas con Postgres en producción, seguramente ya te pasó esto: la app funciona bien en desarrollo, pero cuando sube el tráfico empiezan los síntomas raros. Las conexiones se multiplican, el servidor se queda sin slots disponibles, el pool de tu framework no alcanza, y de pronto tienes una cola de requests esperando solo para abrir una conexión nueva.

Ahí es donde aparece el viejo problema de siempre: Postgres escala muy bien para muchas cosas, pero no le encanta que cada request abra su propia conexión. Por eso existen los connection poolers. Y por eso también sigue teniendo sentido que aparezca otro más. No porque falten opciones, sino porque el problema no se fue. Cambió el contexto: más contenedores, más despliegues efímeros, más serverless, más presión por bajar costos y menos tolerancia a operar infraestructura frágil.

El problema real no es Postgres, son las conexiones

Postgres maneja conexiones de forma costosa. Cada conexión consume memoria, procesos o workers, y además agrega presión operativa cuando tu app crece por horizontal scaling. Si levantas 10 instancias de tu API y cada una abre 20 conexiones, ya estás en 200 conexiones potenciales antes de contar jobs, workers de background, migraciones o herramientas internas.

Ese número no suena grave hasta que lo comparas con configuraciones comunes. En muchos despliegues, max_connections se deja en 100, 200 o 500. Si tu aplicación, tus jobs y tus scripts de mantenimiento compiten por esos slots, el problema no es teórico. Es producción.

El pooler existe para desacoplar el número de clientes del número de conexiones reales a la base. En vez de que cada request tenga su sesión dedicada, el pooler reutiliza conexiones y reduce el costo de mantenerlas vivas. Eso baja latencia, evita saturación y te permite crecer sin tocar la base cada dos semanas.

Qué pasa cuando no usas pooling

Sin pooling, el patrón típico es este:

1. Tu API recibe un pico de tráfico.
2. Cada instancia intenta abrir más conexiones.
3. Postgres empieza a rechazar nuevas conexiones o a gastar más recursos en administración.
4. Tu app responde más lento o falla.
5. Terminas subiendo CPU, RAM o tamaño de instancia para tapar un problema de diseño.

Ese último punto es el que más duele en la factura. Muchas veces el salto de costo no viene por consultas pesadas, sino por demasiadas conexiones ociosas. Tener 300 conexiones abiertas no significa que estés haciendo 300 veces más trabajo. A veces significa que estás pagando por capacidad que no usas bien.

Por qué otro pooler sí tiene sentido

La pregunta obvia es: si ya existen PgBouncer, Odyssey y otras alternativas, ¿para qué construir otro? La respuesta no es “porque sí”. Es porque cada equipo se topa con una mezcla distinta de restricciones: compatibilidad con prepared statements, comportamiento con transacciones largas, observabilidad, simplicidad operativa, despliegue en contenedores y facilidad para integrarlo en pipelines modernos.

Un pooler nuevo no compite solo por hacer lo mismo. Compite por encajar mejor en un contexto actual. Hoy no basta con reducir conexiones. También tienes que pensar en cómo se comporta en Kubernetes, cómo se actualiza sin downtime, cómo expone métricas y cómo afecta el debugging cuando algo falla.

La idea central es simple: si el cuello de botella sigue vivo, todavía hay espacio para una herramienta más enfocada. No porque las anteriores sean malas, sino porque el mercado cambió y los equipos tienen necesidades más específicas.

Lo que suele fallar en la operación diaria

En la práctica, los problemas no aparecen en el benchmark bonito. Aparecen aquí:

• Deploys donde cada pod arranca con su propio pool y multiplica conexiones.
• Workers de background que mantienen conexiones abiertas aunque estén inactivos.
• Lambdas o jobs efímeros que conectan y desconectan todo el tiempo.
• Consultas largas que bloquean el pool y hacen esperar a otros clientes.
• Falta de visibilidad para saber si el cuello está en la app, el pool o Postgres.

Ese combo hace que el pooler deje de ser un detalle técnico y se vuelva una pieza de arquitectura. Si falla, la app se siente lenta. Si está mal configurado, te puede esconder el problema en vez de resolverlo.

Qué busca resolver un pooler moderno

Un pooler moderno no debería ser solo un multiplexor de conexiones. También debería ayudarte a operar mejor. Eso implica tres cosas: usar menos recursos, mantener compatibilidad razonable con clientes comunes y darte señales claras cuando algo se degrada.

La parte de recursos es la más fácil de entender. Si reduces el número de conexiones activas hacia Postgres, reduces memoria y presión en el servidor. La parte de compatibilidad es más delicada, porque muchas apps dependen de comportamientos específicos del driver o del ORM. Y la parte de observabilidad es la que separa una herramienta útil de una caja negra.

Hay un detalle que mucha gente pasa por alto: no todos los workloads se benefician igual. Un pooler puede ser excelente para tráfico web con requests cortos y peor para procesos que mantienen transacciones largas. Por eso importa tanto elegir bien el modo de pooling y no asumir que una sola configuración sirve para todo.

Session pooling vs transaction pooling

Aquí vale la pena separar dos enfoques comunes:

• Session pooling: cada cliente mantiene una sesión lógica más estable. Es más compatible con ciertos patrones, pero reutiliza menos agresivamente.
• Transaction pooling: el pooler asigna conexiones físicas por transacción. Suele ser más eficiente, pero rompe supuestos de sesión en algunas apps.

No necesitas memorizar teoría para entender el impacto. Si tu app depende de variables de sesión, temp tables o prepared statements persistentes, transaction pooling puede complicarte la vida. Si tu carga es mayormente request-response y las consultas son cortas, suele darte mejor densidad.

La decisión correcta depende del patrón de uso, no del nombre más lindo del producto.

Cómo se traduce esto en costos y capacidad

El beneficio más tangible del pooling es que puedes atender más tráfico con la misma base o con una instancia más pequeña. Eso no siempre significa “ahorrar dinero” de forma inmediata, pero sí evitar el crecimiento prematuro de infraestructura.

Pensemos en un ejemplo simple. Si una app tiene 8 pods, cada uno con 15 conexiones, ya estás en 120 conexiones. Si además tienes 4 workers de background con 10 conexiones cada uno, llegas a 160. Con un pooler, quizá tu base solo necesite 30 o 40 conexiones reales para manejar el mismo volumen, siempre que el patrón de trabajo lo permita.

Esto no elimina la necesidad de optimizar consultas. Solo evita que el costo de coordinación entre app y base se vuelva el principal problema. En equipos pequeños o medianos, ese detalle marca la diferencia entre crecer con calma o pasar semanas afinando parámetros de conexión.

Tabla de impacto típico

Ese tipo de números no es una promesa universal. Dependen de tu carga, de tu driver y de cómo configures el pool. Pero sí muestran por qué el problema sigue vigente: la relación entre clientes y conexiones reales sigue siendo una fuente de costo y fragilidad.

Qué cambia en arquitecturas modernas

Hoy muchas apps ya no viven en una sola VM con un proceso estable. Viven en contenedores, en clusters que escalan por demanda, en funciones efímeras o en servicios que se reinician seguido. Eso cambia el comportamiento del tráfico hacia la base.

Antes, el problema era “mi app abre demasiadas conexiones”. Ahora es “mis 15 réplicas, mis jobs y mis tareas temporales abren demasiadas conexiones al mismo tiempo”. El pooler deja de ser una optimización y pasa a ser una capa de control.

Además, hay un factor operativo muy concreto: cuando la infraestructura se vuelve más dinámica, depurar problemas de conexión se vuelve más difícil. Un pooler bien diseñado puede darte métricas más útiles y un punto claro para aplicar límites, timeouts y backpressure.

Señales de que necesitas pooling ya

Si ves una o varias de estas señales, no estás imaginando el problema:

• too many clients already en logs de Postgres.
• CPU moderada pero latencia alta por espera de conexión.
• Pods o workers con muchas conexiones idle.
• Tiempo de arranque alto en nuevas réplicas.
• Costos subiendo por instancias más grandes sin mejora proporcional.

No necesitas esperar a una caída total para actuar. Si ya estás cerca del límite de conexiones o si tu base se siente frágil en horas pico, el pooler suele ser una de las primeras piezas a revisar.

Qué evaluar antes de adoptar uno

No todos los poolers te sirven igual, y no todos los equipos necesitan la misma configuración. Antes de meter uno en producción, conviene revisar compatibilidad, observabilidad y operación diaria. Si te saltas esa parte, puedes resolver un problema y crear otro.

Lo mínimo que yo revisaría es esto:

1. Compatibilidad con tu driver y ORM: verifica si dependes de prepared statements, session variables o temp tables.
2. Modo de pooling: define si necesitas session o transaction pooling según tu carga.
3. Métricas y logs: necesitas ver conexiones activas, esperas, rechazos y tiempos de cola.
4. Failover y reconexión: revisa qué pasa cuando Postgres se reinicia.
5. Despliegue: confirma si corre bien en tu entorno actual, sea VM, Docker o Kubernetes.

También conviene mirar documentación oficial de Postgres sobre conexiones y límites, porque ahí está la base del problema. La documentación de max_connections y el costo de manejar muchas conexiones ayuda a entender por qué el pooling existe en primer lugar: https://www.postgresql.org/docs/current/runtime-config-connection.html

Si tu stack usa un proxy o balanceador delante de la base, revisa también cómo se comportan los timeouts y las conexiones persistentes. No todo el tráfico de red se ve igual desde el punto de vista de la base de datos.

Qué aporta un pooler nuevo al ecosistema

Un pooler nuevo no solo agrega otra opción. También obliga a revisar supuestos que se dieron por sentado durante años. Por ejemplo, que escalar Postgres significa subir de tamaño la instancia. O que el problema de conexiones se resuelve con más RAM. O que un pooler es algo que instalas una vez y olvidas.

La realidad es más práctica. Si tu arquitectura cambia cada seis meses, tu capa de acceso a datos también tiene que adaptarse. Un pooler nuevo puede ser interesante si simplifica esa adaptación, ofrece mejor observabilidad o reduce fricción en entornos modernos.

Esto no significa tirar por la borda herramientas conocidas. Significa aceptar que el problema sigue ahí y que vale la pena seguir explorando formas más limpias de resolverlo. En especial si trabajas en Latinoamérica, donde el costo de infraestructura pega más fuerte y muchas veces necesitas exprimir al máximo una sola base bien configurada antes de pensar en escalar horizontalmente.

La documentación oficial de PgBouncer también ayuda a comparar enfoques y entender sus modos de operación: https://www.pgbouncer.org/usage.html

Tabla resumen

Si quieres medir impacto real en tu sistema, empieza por contar conexiones por servicio, pico horario y tiempo promedio de espera para obtener una conexión. Con esos tres datos ya puedes saber si el problema es teórico o si está drenando capacidad de verdad.