This page is for developers, DBAs and platform engineers who have hit connection limits, need read replicas to take real traffic, want failovers to stop breaking applications, or are planning to shard. The tools listed here are often grouped under the word "proxy", but they solve different problems, so each listing carries one of six labels. Connection poolers share a small number of server connections among many clients (PgBouncer, Odyssey, Amazon RDS Proxy). Database proxies understand the database protocol and add routing, read/write splitting and failover handling (Pgpool-II, ProxySQL, MariaDB MaxScale, MySQL Router). Load balancers such as HAProxy forward TCP connections without understanding SQL.
Sharding and routing layers spread one logical database over many servers (Vitess for MySQL, Apache ShardingSphere). A database extension such as Citus does the sharding inside PostgreSQL itself and is not a network proxy. An authentication proxy such as Google's Cloud SQL Auth Proxy handles IAM authorisation and encryption, and Google documents that it does not pool connections. Two licence changes matter here: MariaDB MaxScale has been proprietary since version 25.01 and needs a MariaDB Enterprise subscription for production, while ProxySQL remains GPL v3.
What this software does
Database connections are expensive. PostgreSQL starts a server process for each connection, and both PostgreSQL and MySQL cap connections with max_connections; when the cap is reached, clients see errors such as PostgreSQL 53300 too many clients or MySQL 1040 too many connections. A connection pooler accepts many client connections and lends them a smaller set of server connections. In session pooling a client keeps one server connection until it disconnects; in transaction pooling it borrows one only for the length of a transaction, which saves the most connections but breaks session state such as SET, LISTEN, session advisory locks and SQL-level PREPARE. Amazon RDS Proxy handles the same problem by pinning a client to one connection when it detects session state.
A database-aware proxy speaks the MySQL or PostgreSQL wire protocol and can inspect each statement. That lets it send writes to the primary and reads to replicas, apply query rules (ProxySQL can rewrite, cache, mirror or block statements), track which server is the current primary and retry or replay work after a failover. Read/write splitting creates a read consistency question, because replicas lag the primary; tools answer it with lag thresholds (Pgpool-II) or causal reads (MaxScale). A generic load balancer works at the TCP layer instead: it health-checks servers and forwards connections, but cannot split a session's statements or pool connections, and it needs a role-aware check (for example against an HA agent such as Patroni) to know which PostgreSQL server is the primary.
Sharding layers go further: they present many databases as one and route each query by a shard key. Vitess places VTGate, a MySQL-protocol query router, in front of sharded MySQL; ShardingSphere works as a Java JDBC library or as a MySQL- and PostgreSQL-protocol proxy; Citus achieves a similar result inside PostgreSQL by distributing tables across nodes. These change how schemas and queries must be designed. Authentication proxies solve a different problem again: they replace IP allowlists and certificate management with identity-based access and encrypted tunnels, while the database still sees ordinary connections.
Types of product in this category
- Connection pooler: Shares a limited number of server connections among many client connections, with session or transaction pooling; PgBouncer and Odyssey for PostgreSQL, and the managed Amazon RDS Proxy for RDS and Aurora.
- Database proxy: Understands the database protocol and adds read/write splitting, query routing and failover handling on top of connection management (Pgpool-II for PostgreSQL; ProxySQL, MaxScale and MySQL Router for the MySQL family).
- Sharding and routing layer: Presents many database servers as one logical database and routes each query to the right shard by a sharding key (Vitess for MySQL, Apache ShardingSphere for MySQL and PostgreSQL).
- Load balancer: A generic TCP and HTTP load balancer such as HAProxy that health-checks servers and forwards connections, without parsing SQL, pooling connections or handling database authentication.
- Authentication proxy: Handles identity-based authorisation and encryption between an application and a managed database, such as the Cloud SQL Auth Proxy with IAM and TLS 1.3, and does not pool or balance connections.
- Database extension: Runs inside the database rather than in front of it; Citus is a PostgreSQL extension that shards tables or schemas across nodes and routes queries to the shards that hold the data.
Typical use cases
Serverless and short-lived connections
AWS Lambda functions and other short-lived workers open many connections in bursts. A pooler such as RDS Proxy or PgBouncer absorbs the bursts so the database keeps a steady, small set of connections.
Many application instances on PostgreSQL
Dozens of containers each holding their own pool can exhaust PostgreSQL connections. Transaction pooling with PgBouncer or Odyssey lets thousands of client connections share a few hundred server connections, as long as the application avoids session state.
Scaling reads onto replicas
Send reporting and read-heavy traffic to replicas without changing every query in the application. ProxySQL query rules, MaxScale Readwritesplit, MySQL Router read-only routes and Pgpool-II load balancing all do this, with different controls for replica lag.
Hiding failovers from applications
Keep one stable endpoint while the primary changes. MySQL Router follows InnoDB Cluster metadata, MaxScale monitors drive automatic failover and can replay transactions, and HAProxy can route by a role-aware health check.
Sharding a database that has outgrown one server
Split a very large MySQL database with Vitess, or distribute PostgreSQL tables with Citus, when vertical scaling and read replicas are no longer enough. Expect schema and query changes around the sharding key.
Secure access to managed databases
Connect applications, laptops and CI jobs to Cloud SQL through the Cloud SQL Auth Proxy using IAM roles, without managing SSL certificates or IP allowlists.
How to choose
- Engine and topology fit. Most tools serve one engine family. PgBouncer, Odyssey and Pgpool-II are PostgreSQL only; MySQL Router is built around InnoDB Cluster and ClusterSet; MaxScale is designed for MariaDB; Vitess shards MySQL and Percona Server. ProxySQL covers both MySQL and, since its 3.x line, PostgreSQL. HAProxy works with any TCP database because it does not parse the protocol.
- Pooling model and session-state compatibility. Check which pooling modes exist and what your drivers and ORM need. Prepared statements are the common trap: PgBouncer supports protocol-level prepared statements in transaction mode since 1.21, Odyssey supports them with pool_reserve_prepared_statement, and RDS Proxy pins connections on PREPARE, SET and similar statements for PostgreSQL, which reduces the savings.
- Read/write splitting and read consistency. If you route reads to replicas, decide how stale a read may be. Pgpool-II can skip replicas past a lag threshold, MaxScale offers several causal_reads modes, ProxySQL routes by rules you define, and MySQL Router splits automatically only with connection sharing on the classic protocol. PgBouncer and Odyssey do not parse statements, so splitting means separate connection entries.
- Failover and primary detection. A proxy that cannot tell which server is the primary can send writes to a read-only replica. PgBouncer has no primary detection; HAProxy's built-in pgsql-check cannot distinguish a primary from a replica; Pgpool-II, MaxScale, MySQL Router and ProxySQL track topology for their supported clusters; Vitess uses VTOrc for reparenting.
- Throughput and threading. PgBouncer is single-threaded (one CPU core per process), so high-throughput sites run several processes with so_reuseport; Odyssey is multi-threaded in one process. Size the proxy tier for peak connection and query rates, and place it close to the application to limit added network hops.
- High availability of the proxy itself. The proxy becomes part of every request path. Pgpool-II uses a watchdog that needs at least three nodes, ProxySQL Cluster synchronises configuration between nodes, Vitess VTGates are stateless and scale horizontally, and MySQL Router is usually deployed next to each application host.
- Authentication and TLS. Check which authentication methods reach the database (SCRAM-SHA-256, LDAP, PAM, certificates, cloud IAM) and whether TLS is supported on both the client and server side. Pgpool-II does not support GSSAPI, MySQL Router does not support Kerberos, and HAProxy leaves database authentication to the database.
- Licence and release line. Licences and release models changed recently. MaxScale moved to a proprietary licence with 25.01 and production use needs a MariaDB Enterprise subscription; ProxySQL ships Stable, Innovative and Plugin tiers under GPL v3; MySQL Router moved to a single release line in July 2026; Vitess v24 is the last release to support MySQL 8.0; ShardingSphere releases have slowed.
- Managed or self-hosted. Managed poolers remove operations but limit control: RDS Proxy supports only RDS and Aurora targets in the same VPC, and several managed PostgreSQL services bundle PgBouncer. Self-hosted tools run anywhere but you own upgrades, monitoring and HA.