Primero, lea nuestra pregunta canónica sobre Planificación de capacidad .
El consejo específico que está solicitando es un consejo de planificación de capacidad, y tendrá que resolverlo por su cuenta, para su entorno particular.
En segundo lugar, estás mirando esto mal.
La cantidad de memoria (o cualquier otro recurso) que tenga no dicta la cantidad de conexiones que establece, la cantidad de conexiones que necesita determina qué tan robusto debe comprar un servidor.
Los requisitos de recursos por conexión se dan en el manual con considerable detalle, así como se discuten en el Wiki al que se vinculó. Averigüe qué necesita su entorno (o haga una suposición bien informada) y asegúrese de que el hardware con el que va a ejecutar pueda manejar lo que le va a lanzar.
Específicamente con respecto a los límites de conexión y el tamaño del grupo, debe tener conexiones "suficientes" para cumplir con los requisitos de su aplicación, ya sea en un solo servidor o mediante un grupo / gorila.
"Suficiente" es un número relativo: una aplicación que realiza (y reutiliza continuamente) una conexión solo requiere una conexión. Una aplicación que establece una conexión para cada usuario final que inicia sesión requiere tantas conexiones de base de datos como usuarios.
Los valores predeterminados para ambos Postgres y pgbouncer
son sensibles como predeterminados :
100 conexiones de base de datos es mucho para la persona típica que lanza Postgres a un entorno.
Los desarrolladores probablemente no necesitarán más de 10. Cualquier otra persona sabrá lo suficiente como para aumentar el número.
20 conexiones pgbouncer
por grupo de base de datos significa que puede obtener 4 grupos apuntando a un servidor y no abrumar el límite de conexión predeterminado de Postgres.
Es posible tener múltiples recursos agrupados pgbouncer
apuntando a una base de datos de fondo, y siempre desea tener algunas conexiones disponibles en sus servidores de fondo.
Si los valores predeterminados no son adecuados para su entorno, se espera que los cambie.
Recuerde que las conexiones agrupadas no significan "atar siempre cada conexión de base de datos disponible".
El punto de pgbouncer
lo que notó es reutilizar las conexiones. La ganancia de eficiencia aquí no requiere que conecte todas las conexiones disponibles, simplemente que no desconecte, vuelva a conectar, renegocie SSL, vuelva a autenticarse en la base de datos y vuelva a ejecutar sus consultas de configuración de conexión cada vez.