PgBouncer vs Supavisor vs PgCat: ¿qué agrupador Postgres?

PgBouncer minimiza, Supavisor agrupa en una escala de múltiples inquilinos, PgCat agrega funciones de red a la agrupación sin formato. Ninguno de los tres reemplaza directamente a los otros dos, aunque a menudo se comparan término por término en las mismas páginas.

Columnas, en orden: PgBouncer, Supavisor, PgCat. Características de la arquitectura según las presentaciones oficiales de cada proyecto, a confirmar en la versión que se esté implementando, el ecosistema evoluciona rápidamente en este punto.

PgBouncer solo hace una cosa: agrupar conexiones Postgres, sin ninguna función adicional. Este alcance deliberadamente estrecho explica en gran medida su longevidad y su adopción como componente básico en la mayoría de las pilas de Postgres en producción.

Hay tres modos de agrupación disponibles. El modo de sesión abre una conexión de servidor por conexión de cliente, la más permisiva. El modo de transacción reutiliza una conexión de servidor entre varios clientes, liberada en cada extremo de una transacción. El modo declaración va aún más allá y rara vez se utiliza en producción. Es el modo de transacción el que genera la ganancia real de la agrupación, pero impone reglas estrictas. Cualquier estado de sesión (variablesSET, bloqueos de aviso, LISTEN/NOTIFY) no sobrevive más allá de una transacción. Detallamos estas reglas y sus trampas en nuestro artículo dedicado sobre el modo de agrupación de transacciones de PgBouncer.

Históricamente, una instancia de PgBouncer es de proceso único y utiliza un único núcleo de CPU de forma predeterminada. La ejecución de varias instancias detrás del mismo puerto (a través de SO_REUSEPORT) es una evolución más reciente del proyecto, no una característica de diseño inicial. En el lado de la autenticación, PgBouncer admite una auth_queryconfigurable, una función SQL ejecutada en cada conexión para resolver dinámicamente la contraseña de un rol. Este mecanismo evita depender de un archivo estático que enumere a cada usuario de antemano. Es exactamente este mecanismo el que utiliza Aurabase para sus funciones por proyecto (sección 05).

Supavisor aborda un problema para el que PgBouncer nunca fue diseñado a esta escala. Esto implica servir a una gran cantidad de bases de datos de inquilinos distintas desde un único servicio, en lugar de una instancia de agrupación por base de datos. Escrito en Elixir y ejecutado en la máquina virtual Erlang (BEAM), el proyecto es desarrollado y mantenido por Supabase, en código abierto, en su propio repositorio GitHub.

El modelo nativo multiinquilino es la verdadera diferencia estructural. Cuando una flota clásica de PgBouncer requiere un proceso (o un conjunto de conexiones dedicadas) por base objetivo, Supavisor funciona de manera diferente. Registra dinámicamente a los inquilinos a través de una interfaz de administración HTTP y enruta cada conexión entrante a la base de datos correcta sin reiniciar el servicio. Supabase migró sus propios proyectos de nube de PgBouncer a Supavisor por esta misma razón. Un clúster de agrupación clásico, uno por base de datos, no se adapta a una nube multiinquilino que aloja cientos de miles de proyectos.

Esta elección arquitectónica tiene una desventaja documentada. La paridad de funciones con PgBouncer en casos avanzados tardó en estabilizarse después del lanzamiento del proyecto. Dos ejemplos: ciertos comportamientos de LISTEN/NOTIFYy la gestión fina de declaraciones preparadas en modo transacción. Verifique su versión antes de la migración si su aplicación depende de estos comportamientos específicos.

PgCat se posiciona explícitamente como una alternativa a PgBouncer, escrito en Rust. Agrega funciones de red a la agrupación clásica que ni PgBouncer ni Supavisor incorporan de forma nativa. Tres en particular: fragmentación de aplicaciones por clave de partición, equilibrio de carga entre réplicas de lectura y conmutación por error automática lejos de una réplica fallida. El proyecto nació en Instacart antes de ser asumido y mantenido hoy por PostgresML.

Concretamente, PgCat puede desempeñar el papel que normalmente ocuparían dos capas distintas: un agrupador de conexiones y un proxy de aplicación para enrutamiento entre varias instancias de Postgres. Un equipo que ya estaba fragmentando sus datos a mano puede simplificar su código con PgCat. Lo mismo ocurre con una lógica para distribuir lecturas entre réplicas desarrollada internamente: una capa de red dedicada la reemplaza directamente.

También existe el compromiso opuesto: PgCat es un proyecto más joven, con un ecosistema de documentación y retroalimentación de producción mucho más pequeño que PgBouncer. Adoptar sus funciones de fragmentación y conmutación por error también significa aceptar depender de la madurez de este componente específico, no solo de su capacidad de agrupación.

El repositorio de Aurabase implementa PgBouncer en dos niveles separados, ambos en modo de transacción. Para la flota compartida, el gráfico Helm define una implementación de PgBouncer dedicada frente al plano de datos compartido (deploy/helm/aurabase/templates/infra/pgbouncer.yaml, imagen edoburu/pgbouncer). Para un inquilino en una instancia dedicada, el aprovisionador genera un recurso Pooler administrado de forma nativa por CloudNativePG (deploy/cnpg/tenant-pooler.yaml, representado por k8s_tenant.rs). Tampoco utiliza Supavisor o PgCat. El código no documenta una comparación explícita que precedió a esta elección. Por otro lado, muestra una integración profunda y ya operativa con el ecosistema CloudNativePG, consistente con el hecho de que PgBouncer es el bloque de pooling nativo.

Sin embargo, no todo pasa por el pooler, y esta es una elección deliberada documentada en el propio código. PostgREST permanece conectado en vivo a Postgres, nunca a través de PgBouncer. El comentario del gráfico Helm es explícito sobre el motivo: la agrupación de transacciones interrumpiría la recarga del esquema, que depende de un LISTEN en el canal pgrst. Este mecanismo es incompatible con conexiones de servidor recicladas entre clientes. El grupo de administraciónaura-db (esquema, DDL, bloqueos de aviso de sesión) también permanece en conexión directa, por la misma razón básica. Los SET search_path sin ámbito de transacción y los bloqueos de sesión no sobreviven a un agrupador en modo de transacción.

# Plano de datos aura-db: a través de PgBouncer, todo tiene un alcance de transacción (SET LOCAL)
DATABASE_URL: postgresql://aura_authenticator:...@pgbouncer:5432/aura_db_master

# Administrador del grupo (DDL, introspección): DIRECTO en Postgres, nunca PgBouncer
# SET search_path no LOCAL + bloqueos de sesión interrumpen la agrupación de transacciones
ADMIN_DATABASE_URL: postgresql://aura:...@postgres:5432/aura_db_master

La autenticación sigue el patrón auth_query descrito en la sección 02: AUTH_QUERY: SELECT * FROM pgbouncer.user_lookup($1), sin un archivo userlist.txt estático. Esto es lo que permite que los roles creados dinámicamente por proyecto (project_<uuid>_authenticator) se autentiquen a través de PgBouncer sin volver a implementar el pooler para cada nuevo proyecto.

Un último detalle, menor pero revelador: el gráfico Helm fija edoburu/pgbouncer:v1.24.1-p1 de forma predeterminada, mientras que el banco k3d local usa v1.25.2-p0. No es una elección arquitectónica, sólo una ligera falta de sincronización de versiones entre dos entornos, el tipo de detalle que una revisión de código capta más rápido que una publicación de blog. Lo documentamos tal como es en lugar de disfrazarlo. Para obtener detalles sobre la partición del esquema que ofrece este agrupador, consulte nuestro artículo sobreaislamiento RLS multiinquilino.

Elija PgBouncer si…

• Clúster de Postgres administrado por CloudNativePG o Kubernetes en general
• Quiere el pooler más probado y mejor documentado
• Una base de objetivos por instancia de pooler le conviene

Elija Supavisor si…

• Cientos o miles de bases detrás de un mismo servicio
• Necesidad de registrar inquilinos dinámicamente a través de una API, sin redistribución
• Ya en el ecosistema de Supabase o dispuesto a depender de él.

Elija PgCat si...

• El uso compartido de aplicaciones ya está implementado o planificado a nivel del pooler
• Equilibrio de carga y réplica de conmutación por error sin capa de aplicación separada
• Cómodo con un proyecto más joven, menos documentado que PgBouncer

Cualquiera que sea el pooler elegido, no reemplaza el tamaño del propio Postgres. El tamaño del grupo y el servidor max_connections deben considerarse juntos, no uno tras otro. Un grupo generoso frente a un max_connections demasiado bajo simplemente cambia la saturación de un nivel a otro. Nuestra guía sobre ajuste de max_connections detalla la fórmula de tamaño que se debe aplicar antes de configurar el tamaño de su piscina.

PgBouncer, Supavisor y PgCat resuelven tres variaciones del mismo problema, no tres versiones de la misma herramienta. PgBouncer sigue siendo la opción más segura cuando su plataforma ya depende de Kubernetes y CloudNativePG, o cuando simplemente desea el pooler más documentado. Supavisor adquiere relevancia más allá de un cierto número de bases que atienden desde el mismo servicio. Vale la pena desviarse de PgCat si omite la fragmentación y la conmutación por error de réplica a nivel de red, siempre que acepte la madurez de un proyecto más joven.

El código de Aurabase muestra una elección consistente, no neutral: PgBouncer en modo de transacción, en dos niveles, flota compartida y agrupador de CNPG por inquilino dedicado. Quedan dos excepciones documentadas, para PostgREST y para la administración de esquemas. Si desea ver este proyecto aislado en acción en lugar de en papel, nuestra página Rendimiento documenta la metodología de medición asociada.