PgBouncer

PgBouncer is a self-hosted connection pooler for PostgreSQL that lets applications reuse server connections rather than repeatedly opening new ones. It is best suited to teams comfortable operating database infrastructure and needing efficient connection management without a licensing bill. Its narrow focus is a strength for pooling, but high-availability designs need companion services.

Overview

PgBouncer mediates PostgreSQL connections and can send clients to databases on different hosts, so deployment is not tied to one backend server. It does not perform internal multi-host load balancing or detect failed hosts. DNS reconfiguration or an external TCP balancer such as HAProxy or LVS is therefore required when traffic distribution or failover is part of the architecture.

The project, founded in 2007, is available as source releases, native operating-system packages, and dedicated RPM and Debian repositories. Version 1.26.0, released September 23, 2026, fixes three denial-of-service CVEs. Operators should therefore treat timely upgrades as part of running it responsibly.

Key features

Pooling modes

Session, transaction, and statement pooling provide different trade-offs in connection reuse. Session pooling keeps a backend connection with a client for the whole session and is the least disruptive choice for applications that depend on session state. Transaction pooling returns connections after each transaction, improving reuse while imposing stricter application behavior. Statement pooling is the most aggressive option, but it disallows multi-statement transactions and is unsuitable for software that requires them.

Prepared statements and memory

In transaction and statement modes, protocol-level prepared statements can be tracked when max_prepared_statements is non-zero. That helps retain prepared-statement use under more efficient pooling modes, provided the setting is configured deliberately. The documented default memory requirement is 2 kB per connection, a useful planning figure for installations handling many concurrent connections.

Security and deployment

Authentication options include client certificates, SCRAM-SHA-256, LDAP, PAM, and HBA-based configuration. TLS support requires OpenSSL 1.0.1 or later at build time. Building also requires Libevent 2.0 or later, pkg-config, and a C11-capable compiler; PAM, LDAP, and systemd integrations are optional. Windows operation is documented, but MinGW is the only supported Windows build environment, making Linux the more natural choice for many server teams.

Pricing

PgBouncer — free. The free plan is the software itself: a source release for self-hosted deployment. There is no paid tier, usage charge, or free trial. You supply the infrastructure, installation, upgrades, authentication setup, and operational support, so the zero price is most valuable to organizations already equipped to run PostgreSQL services.

Platforms

PgBouncer supports Linux, self-hosted deployments, and Windows. Windows builds depend on MinGW, while builds with TLS require OpenSSL and the other stated development dependencies. Package repositories and native operating-system packages can reduce installation work compared with compiling from source.

Who it's for

Choose PgBouncer when PostgreSQL connection churn is a performance concern, your applications can follow the constraints of the selected pooling mode, and your team wants direct control over deployment. It is particularly compelling for self-hosted Linux environments that need a small, focused pooler and can add DNS or an external load balancer for topology management.

Look elsewhere when you need built-in host balancing, automatic failover detection, or a managed service. Statement-heavy applications that require multi-statement transactions should avoid statement pooling, and teams without capacity for builds, upgrades, and authentication administration may prefer a more managed option.

Pros and cons

• Pro: Three pooling modes let operators match connection reuse to application transaction behavior.
• Pro: Routing to databases on different hosts avoids a single-backend restriction.
• Pro: Broad authentication choices and protocol-level prepared-statement tracking support hardened, efficient deployments.
• Pro: The software is free and self-hosted, with source and multiple package distribution paths.
• Con: No internal load balancing or failover detection means extra DNS or infrastructure components are required.
• Con: Statement pooling forbids multi-statement transactions, limiting compatibility for some applications.
• Con: Windows support is constrained to MinGW, and self-hosting leaves operations and security maintenance to your team.

Alternatives

For a wider selection, browse Database Proxy Software.

• MySQL is the better pick when you need a full database platform with SQL and NoSQL applications, replication and high-availability components, and connectors across more operating systems.
• OceanBase Database suits teams seeking a distributed database with full kernel capabilities and both community and enterprise editions.
• PgDog is worth considering for an AGPL-3.0 PostgreSQL-focused alternative with an optional enterprise control plane and insights.
• ShardingSphere-Proxy fits deployments wanting an open-source proxy distributed with Docker and Helm options.
• TurbineProxy offers an Apache-2.0 open-source proxy with no per-query fees.
• pgagroal is another BSD-3-Clause, self-hosted PostgreSQL connection pool.
• PgDoorman is a free self-hosted PostgreSQL pooler with no paid plans or stated usage limits.
• ProxySQL is the alternative for teams wanting a broader open-source proxy with community and enterprise offerings.

Verdict

PgBouncer is a strong choice for PostgreSQL operators who want proven, focused connection pooling, flexible pooling modes, and zero software cost under self-hosting. Choose it for connection reuse and control; choose another solution, or pair it with external infrastructure, when balancing and automatic failover are requirements.