Pooling de connexions Postgres avec PgBouncer — les patterns que nous utilisons en production

Les connexions Postgres sont coûteuses. Un seul backend Postgres inactif utilise 5-15 Mo de mémoire et tient des ressources OS qui ne se libèrent pas avant la fermeture de la connexion. La plupart des frameworks applicatifs ouvrent des dizaines de connexions par instance, multipliez par les replicas, multipliez par les environnements — et vous obtenez vite 500-2000 connexions vers une DB qui performe au mieux à peut-être 100.

C'est à cela que sert PgBouncer. Nous le déployons pour presque chaque client Postgres managé, et il reste l'outil d'ops Postgres avec le plus haut levier.

Une config de transaction-pooling de base

[databases]
app = host=db.internal port=5432 dbname=app
 
[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
pool_mode = transaction
max_client_conn = 5000
default_pool_size = 25
server_lifetime = 3600
server_reset_query = DISCARD ALL
max_prepared_statements = 100

Par défaut, transaction pooling. Utilisez le session pooling uniquement pour le sous-ensemble spécifique de workloads qui ont besoin de LISTEN/NOTIFY, d'advisory locks ou de tables temp — idéalement sur un port séparé.

L'article complet couvre :

• Session vs transaction vs statement pooling — quand chacun est correct
• Dimensionner default_pool_size contre votre max_connections Postgres réel
• Lire SHOW POOLS; pendant la charge de pointe pour ajuster
• Le support natif des prepared statements dans PgBouncer 1.21+ (et le retrait du contournement côté client)
• Un PgBouncer par hôte app vs cluster centralisé — les trade-offs
• auth_query pour que les credentials ne quittent jamais Postgres

Nous livrons cela sur chaque déploiement Postgres managé.