Postgres-Connection-Pooling mit PgBouncer — die Patterns, die wir in Produktion fahren

Postgres-Verbindungen sind teuer. Ein einzelnes leerlaufendes Postgres-Backend braucht 5-15 MB Speicher und hält OS-Ressourcen, die erst beim Schließen der Verbindung freigegeben werden. Die meisten Application-Frameworks öffnen Dutzende Verbindungen pro Instanz, multipliziert mit Replicas, multipliziert mit Umgebungen — und schon haben Sie 500-2000 Verbindungen zu einer DB, die am besten bei vielleicht 100 läuft.

Dafür ist PgBouncer da. Wir deployen es für fast jeden gemanagten Postgres-Kunden, und es bleibt das Postgres-Ops-Werkzeug mit dem höchsten Hebel.

Eine Transaction-Pooling-Basis-Konfig

[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

Standardmäßig Transaction-Pooling. Nutzen Sie Session-Pooling nur für die spezifische Teilmenge an Workloads, die LISTEN/NOTIFY, Advisory Locks oder Temp-Tabellen brauchen — idealerweise auf einem separaten Port.

Der vollständige Beitrag behandelt:

• Session vs Transaction vs Statement Pooling — wann jedes richtig ist
• Dimensionierung von default_pool_size gegen Ihr tatsächliches Postgres-max_connections
• SHOW POOLS; während Spitzenlast lesen, um zu tunen
• Native Prepared-Statement-Unterstützung in PgBouncer 1.21+ (und Entfernung des clientseitigen Workarounds)
• Ein PgBouncer pro App-Host vs zentralisiertes Cluster — die Trade-offs
• auth_query, damit Credentials Postgres nie verlassen

Wir liefern das auf jedem gemanagten Postgres-Deployment aus.