Question 1

What does PgBouncer consulting cover?

Accepted Answer

Pool mode selection (session / transaction / statement) - including the application-compatibility implications, connection pool sizing modelled against backend max_connections + active session distribution, PgBouncer vs RDS Proxy vs pgcat decision, prepared-statement handling (workarounds for transaction-pooling mode), TLS/SSL configuration, HA topology design (multiple PgBouncer instances with HAProxy or Keepalived). Deliverables are written architecture documents.

Question 2

Session vs Transaction vs Statement mode - which fits?

Accepted Answer

Session mode: one client = one backend connection for full session - simplest, supports all Postgres features but lowest pooling benefit. Transaction mode: backend connection released after each transaction - best pooling efficiency, but breaks features that need session state (SET, LISTEN/NOTIFY, prepared statements in some clients, advisory locks). Statement mode: backend released after each statement - rarely used, breaks transactions entirely. Most production deployments use transaction mode after fixing the session-state compatibility issues.

Question 3

Prepared statements in transaction mode - how do you handle them?

Accepted Answer

Transaction-mode pooling breaks server-side prepared statements because the backend connection rotates per transaction. Solutions: (1) disable server-side prepares in the client driver (PgJDBC: prepareThreshold=0; psycopg: use protocol-level binding without server-side prepare), (2) use PgBouncer 1.21+ with track_prepared_statements which adds support for protocol-level prepared statements (still has constraints), (3) use a connection pooler that handles this better (pgcat, Supavisor). We help pick the right strategy for your stack.

Question 4

PgBouncer vs RDS Proxy - when to use which?

Accepted Answer

RDS Proxy: AWS-managed, IAM integration, automatic failover handling, deep RDS integration, but more expensive and adds per-request latency. PgBouncer: open-source, multi-cloud, very low latency, much cheaper, but needs operational ownership. For AWS-only workloads where managed-service ergonomics matter, RDS Proxy. For multi-cloud, cost-conscious, or low-latency workloads, PgBouncer. The break-even is workload-specific - we model both before recommending.

Question 5

How do you size PgBouncer correctly?

Accepted Answer

Pool sizing depends on: backend max_connections (Postgres default 100 - usually raised to 300-500 for production), active concurrent transactions (NOT total app connections), query latency profile, and burst behaviour. Common formula: backend_pool = backend_max_connections - reserved_admin_slots - replication_slots, distributed across PgBouncer instances. We model your workload (active session distribution, query latency, burst rates) before sizing - defaults are usually wrong by a factor of 2-5.

Question 6

PgBouncer HA topology - what does production look like?

Accepted Answer

Single PgBouncer is a SPOF. Standard HA: multiple PgBouncer instances behind HAProxy, Keepalived, or AWS NLB. Each PgBouncer connects to the same Postgres backend cluster. Config sync via Consul, etcd, or Ansible. For K8s deployments: PgBouncer as a sidecar to each app pod (no SPOF but high backend connection count), or as a Service with multiple Pods (shared cluster behaviour). We design the right pattern for your scale + ops model.

PgBouncer Consulting Services

What our PgBouncer consulting covers

PgBouncer consulting - common questions

Ready to design your PgBouncer topology?