At a glance
| Supported databases | PostgreSQL only (self-managed or managed services) |
| Pooling modes | Session (default), transaction, statement |
| Routing and read/write splitting | No query routing; each logical database maps to a configured host, so read/write splitting is done by pointing clients at separate entries |
| Load balancing and failover | A comma-separated host list per database with load_balance_hosts (round-robin by default, or stick to one host until it fails); no primary detection, so HA is usually handled by Patroni, DNS, a VIP or HAProxy |
| Authentication and TLS | cert, md5, scram-sha-256, ldap, pam, hba, trust; auth_file or auth_query; TLS to clients and servers |
| Prepared statements | Protocol-level prepared statements in transaction mode since 1.21; SQL PREPARE not supported in transaction mode |
| Deployment | Self-hosted binary or package on Linux and BSD; Windows via MinGW build; bundled in some managed services |
| Licensing | ISC licence, free |
PgBouncer is the default answer when PostgreSQL runs out of connections: a small single-purpose pooler that sits in front of the server and shares a few backend connections among many clients. It does not balance load, split reads from writes or handle failover, so pair it with other tools when you need those.
Overview
PgBouncer is a connection pooler for PostgreSQL. Clients connect to PgBouncer (by convention on port 6432) as if it were PostgreSQL, and PgBouncer hands them server connections from per-user, per-database pools. It offers three modes: session pooling (a client keeps one server connection until it disconnects; the default), transaction pooling (a server connection is lent only for one transaction) and statement pooling (transaction pooling that forbids multi-statement transactions, mainly for PL/Proxy). The documentation puts memory use at about 2 kB per connection by default.
Transaction pooling is where most of the connection savings come from, and also where the caveats are: session state such as SET, LISTEN, session advisory locks and SQL-level PREPARE do not survive across transactions. Protocol-level prepared statements are supported in transaction mode since 1.21 when max_prepared_statements is non-zero (default 200 since 1.24). Version 1.26.0 (23 September 2026) began tracking every parameter PostgreSQL reports, including search_path on PostgreSQL 18, to stop settings leaking between clients, and removed online restart (-R). For a managed alternative on AWS, see Amazon RDS Proxy.
Key features
- Three pooling modes: session (default), transaction and statement
- Protocol-level prepared statements in transaction pooling via max_prepared_statements (default 200)
- Authentication types cert, md5, scram-sha-256, trust, hba, ldap (since 1.25.0) and pam, plus auth_query to look up passwords in the database
- Client-side and server-side TLS with modes from disable to verify-full
- Admin console (SHOW and control commands) and online reconfiguration of most settings
- Multiple processes on one host with so_reuseport, and peering to forward cancel requests between processes
- Per-user and per-database limits such as default_pool_size, query_wait_timeout and pool_idle_timeout (1.26)
Integrations and ecosystem
Pros and cons
Pros
- Small, single-purpose and widely packaged, with a long release history
- Transaction pooling lets thousands of clients share a small number of server connections
- Prepared statement support in transaction mode removes a long-standing driver problem
- Built into several managed PostgreSQL services, so skills transfer
Cons
- Single-threaded (one CPU core per instance, per the documentation); scaling across cores needs several processes with so_reuseport
- Transaction and statement modes break session features such as SET, LISTEN and SQL PREPARE
- No read/write splitting or query routing, and no detection of which host is the primary
- Online restart was removed in 1.26.0, so upgrades need a planned approach
Pricing
PgBouncer is free, open source software under the ISC licence. There is no paid edition from the project; costs are the servers or containers you run it on and the time to operate it. Several managed PostgreSQL services (for example Azure Database for PostgreSQL flexible server and Neon) include PgBouncer as part of their own pricing.
Pricing checked on the vendor's official page on 7 November 2026. Prices change; confirm before buying.
Who it is best for
PostgreSQL teams that need to cut the number of server connections from many application instances, serverless functions or workers, and want a small open source component they control.
Typical use cases
- Absorbing connection spikes from autoscaled web servers in front of one PostgreSQL primary
- Pooling short-lived connections from serverless functions or job workers
- Running a per-node sidecar pooler in Kubernetes next to the application
- Keeping one pool per tenant role so tenant identity comes from the login, not session state
Who should look elsewhere
- Teams that also need read load balancing, query routing or failover in the same component: consider Pgpool-II.
- AWS teams that prefer a managed pooler with IAM authentication: see Amazon RDS Proxy.
Verdict
PgBouncer is the simplest way to fix PostgreSQL connection exhaustion and the pooler most managed services build on. It deliberately does only pooling, so plan separately for load balancing and failover, and check your application against the transaction-mode limits before switching from session pooling.
Frequently asked questions
Does PgBouncer support prepared statements in transaction mode?
Yes, protocol-level prepared statements (the kind most drivers use) since version 1.21, when max_prepared_statements is set above zero; the default became 200 in 1.24. SQL-level PREPARE and DEALLOCATE commands are still not supported in transaction pooling.
Which pooling mode should I use?
Session pooling is the default and safe for every PostgreSQL feature but saves the fewest connections. Transaction pooling saves the most and suits stateless applications. Statement pooling forbids multi-statement transactions and is mainly meant for PL/Proxy.
Is PgBouncer a load balancer?
Not in the usual sense. It can rotate new server connections across a host list (load_balance_hosts), but it does not split reads and writes or detect a new primary. Teams usually combine it with Patroni, a virtual IP, DNS or HAProxy for failover.
PgBouncer or Amazon RDS Proxy?
RDS Proxy is a managed AWS service billed per vCPU-hour of the database, with IAM authentication and faster Multi-AZ failover, and it also supports MySQL, MariaDB and SQL Server. PgBouncer is free and PostgreSQL-only, and you run and patch it yourself.
Sources
- PgBouncer home page
- PgBouncer features and pooling modes
- PgBouncer configuration reference
- PgBouncer changelog
- PgBouncer GitHub repository
- PgBouncer licence (COPYRIGHT file)
Checked November 2026.
Listed in: Database Proxy & Connection Pooling.
How we research reviews and what star ratings mean: our editorial method.