A Perfect Complement to PostgreSQL
Today’s PostgreSQL ecosystem offers several well established connection pooling options, each with a different scope:
PgBouncer remains the gold standard for focused, battle-tested connection pooling. It does one thing and does it well.
Pgpool-II extends pooling with connection load balancing and high availability features.
pgcat extends connection pooling, adding load balancing, failover, mirroring, and sharding functionality.
The question teams run into as deployments mature is not which connection pooler to choose — it’s where routing, policy, failover reaction, and observability live. A typical PgBouncer-centered middle tier puts the pooler between applications and the PostgreSQL cluster, requires multiple configuration to support read and write connections, then relies on application coding and external tools such as HAProxy to handle traffic. Read/write splitting logic is managed across multiple layers. This works until it doesn’t. When a hot query appears in production, there’s no proxy-side solution. When you want to route a specific workload to a dedicated replica, additional configuration and application logic is required.
At Percona Live Bay Area 2026 we presented ProxySQL – A Perfect Complement to Your PostgreSQL Database and covered how to replace PgBouncer with ProxySQL.
ProxySQL as the PostgreSQL Data Gateway
ProxySQL was built around a different premise: the proxy should be the operational control plane for database traffic, not just a connection manager layer.
Its operating model is SQL-native configuration with runtime activation and persistent state. Every change moves through a three-stage lifecycle: MEMORY → RUNTIME → DISK. You modify in memory, load to runtime to activate immediately with no restart, and persist to disk only when the change proves useful. This means you can experiment on live traffic safely.
Additional features to Pooling and multiplexing that matter in production include Read/write routing, Query policies and Observability.
PgBouncer vs. ProxySQL: A Practical Comparison
PgBouncer is focused and mature in the PostgreSQL ecosystem. ProxySQL, a long-time established MySQL solution provides PostgreSQL support in 3.0.x versions.
| Capability | PgBouncer | ProxySQL |
|---|---|---|
| Pooling | Focused and mature | Advanced Features - MySQL Mature |
| Read/write split | Application or external layer | Query rules + hostgroups |
| Backend monitoring | Liveness probe | Connect, ping, read-only, replication lag |
| Live traffic policy | Not a query-rule engine | Block, route, rewrite, cache, throttle |
| Per-query visibility | External / PostgreSQL side | Proxy-side digest and rule stats |
| Config lifecycle | INI + reload | MEMORY → RUNTIME → DISK |
The architecture difference compounds over time. A PgBouncer-centered middle tier delegates routing, policy, and observability to other layers. A ProxySQL-centered middle tier consolidates them at the proxy, with the HA orchestrator still owning promotion decisions and ProxySQL reacting to role state changes. PgBouncer scales by adding processes — one thread per process. ProxySQL scales vertically inside a single multi-threaded instance, with worker thread count tunable to the matching CPU cores.
Benchmark Results
We benchmarked ProxySQL against PgBouncer. In simple mode, ProxySQL with 4 workers reached approximately 77K TPS at 100 concurrent clients, compared to PgBouncer’s 34K at the same concurrency — roughly a 2.16x advantage at peak. Even with a single worker thread, ProxySQL kept pace with PgBouncer across most concurrency levels.
The relative performance picture across extended and prepared protocols shows ProxySQL with 4 workers delivering between 1.5x and 2.3x PgBouncer throughput at moderate to high concurrency.
At higher concurrency levels ProxySQL consistently outperforms PgBouncer, and the gap widens as worker threads are tuned to available cores.
New ProxySQL Offerings for PostgreSQL
We’re expanding the PostgreSQL tooling ecosystem with two first-party additions.
dbdeployer for PostgreSQL brings the rapid sandbox deployment workflow to PostgreSQL. Dbdeployer is a long familiar and well established product for MySQL users. Deploy a replication topology with ProxySQL included in about 15 seconds. The tool handles binary unpacking, sandbox wiring, and proxysql.cnf pre-configuration. It’s designed for local development, testing, and benchmark reproducibility.
Orchestrator for PostgreSQL brings topology-aware HA management — graceful switchover, API-driven operations, no external consensus requirement — to the PostgreSQL ecosystem as a first-party ProxySQL offering. The HA authority still owns promotion; ProxySQL reacts to role state and rewires traffic accordingly.
Getting Started
If you want to explore ProxySQL with PostgreSQL hands-on, our Docker tutorials repository at https://github.com/proxysql/tutorials covers the progression from a simple connection benchmark through read/write splitting, replica load balancing, and advanced query routing rules — each as a self-contained tutorial.
In a followup post we demonstrate how to use dbdeployer for easier evaluation of ProxySQL with varying PostgreSQL configurations for versions 12 to 18.