Amazon RDS Proxy vs PgBouncer

Quick verdict

Amazon RDS Proxy is a fully managed database proxy for Amazon RDS and Aurora. The application connects to the proxy endpoint; the proxy keeps a pool of database connections and, by default, can reuse a connection after each transaction (AWS calls this multiplexing). It supports Aurora MySQL, Aurora PostgreSQL, RDS for MariaDB, RDS for MySQL, RDS for PostgreSQL and RDS for SQL Server. Clients can be required to authenticate with IAM, and the proxy reaches the database with credentials from AWS Secrets Manager or with IAM database authentication. AWS says it can reduce failover times for RDS Multi-AZ DB instances by up to 66%. For the full background, see Amazon RDS Proxy explained.

PgBouncer is an open source (ISC) connection pooler for PostgreSQL only. You install it on EC2, in containers or as a sidecar, and it offers session (default), transaction and statement pooling. Version 1.26.1 (14 October 2026) is current; 1.26.0 removed online restart (-R) in favour of rolling restarts with so_reuseport.

Side by side

Key differences

Who operates the pooler

RDS Proxy removes the pooler from your operations list. AWS runs the proxy compute serverlessly across Availability Zones, independently of the DB instance; the default endpoint is provisioned across two Availability Zones from the subnets you give it, and you can add up to 20 more endpoints. You configure it through the console, CLI or CloudFormation, monitor it with CloudWatch metrics, and do not patch it. The constraints are AWS ones: 20 proxies per account by default, one target DB instance per proxy, the proxy in the same VPC as the database, and no public access.

PgBouncer is yours to run. You size it, place it (often next to the application or on the database host), make it highly available with more than one instance, and upgrade it. Because 1.26.0 removed online restart, upgrades now use rolling restarts with so_reuseport or several instances behind a balancer. In return you control every setting and can use the same pooler on any PostgreSQL deployment, including outside AWS.

Pooling and pinning on PostgreSQL

Both poolers get their savings by lending a server connection for one transaction at a time, and both struggle with session state. They handle it differently. PgBouncer leaves the choice to you: in transaction mode, session features such as SET, LISTEN and SQL PREPARE are simply not safe, while protocol-level prepared statements work since 1.21. Version 1.26.0 tracks all parameters PostgreSQL reports, including search_path, so those settings do not leak between clients.

RDS Proxy protects correctness automatically by pinning: when it detects a session state change, it keeps that client on the same database connection until the session ends. The User Guide lists the PostgreSQL triggers, including SET commands, PREPARE, DISCARD, DEALLOCATE and EXECUTE, temporary tables, sequences and views, cursors, LISTEN, loading a library such as auto_explain, nextval and setval, and session advisory locks. Session pinning filters exist only for the MySQL engine family. Any statement larger than 16 KB also pins. AWS suggests moving identical SET statements into the proxy's initialization query and watching the DatabaseConnectionsCurrentlySessionPinned metric.

-- PostgreSQL: patterns that pin a session on RDS Proxy
SET search_path TO app;          -- SET commands
PREPARE q AS SELECT 1;           -- SQL-level prepared statements
SELECT nextval('orders_id_seq'); -- sequence functions
-- Prefer: RETURNING instead of lastval()
INSERT INTO orders (customer_id) VALUES (42) RETURNING id;

Failover, authentication and AWS integration

RDS Proxy tracks the current writer of a Multi-AZ deployment and connects to the new primary after failover while preserving application connections; AWS states this reduces failover times by up to 66% for RDS Multi-AZ DB instances. It can enforce IAM authentication for clients and keeps database credentials in Secrets Manager, which suits Lambda functions; the Lambda Developer Guide recommends a proxy for production. It also queues or throttles connections it cannot serve immediately and sheds load beyond the limits you set.

PgBouncer has no failover logic and no IAM integration. On AWS it typically points at the RDS or Aurora cluster endpoint and relies on DNS for failover, or on the approach AWS published for using PgBouncer with RDS Multi-AZ DB clusters. Authentication uses PostgreSQL methods such as SCRAM, certificates, LDAP or PAM, with auth_query to look up passwords in the database.

PostgreSQL feature gaps to check

The RDS User Guide lists PostgreSQL-specific limitations for RDS Proxy: no support for cancelling a query with a CancelRequest (for example Ctrl+C in psql), only version 3.0 of the PostgreSQL messaging protocol, no streaming replication mode, no direct SSL negotiation, inaccurate lastval results (use RETURNING), and the default postgres database must exist. The RDS FAQs also say it can add an average of 5 milliseconds of latency. PgBouncer has its own constraints, mainly the transaction-mode session limits and the single-threaded design, but it is not tied to a cloud provider's feature list.

Pricing and licensing

Amazon RDS Proxy. The pricing page says that for provisioned instances on Aurora, RDS for PostgreSQL, MySQL, MariaDB and SQL Server, RDS Proxy is priced per vCPU of the database instance per hour, and for Aurora Serverless per ACU-hour consumed by the database. The page itself shows no rates; AWS's price data (published 29 October 2026) lists 0.015 USD per vCPU-hour and 0.015 USD per ACU-hour in US East (N. Virginia). Partial hours are billed in 1-second increments with a 10-minute minimum after a billable status change. The default endpoint has no extra charge; additional read-only or read/write endpoints use AWS PrivateLink, billed separately. Example: a proxy in front of a 2-vCPU instance such as db.m8g.large for 730 hours is 2 x 730 x 0.015 = 21.90 USD a month, on top of the database. Prices vary by Region.

PgBouncer. Free under the ISC licence, with no paid edition. Your cost is the EC2 instances, containers or spare capacity it runs on, plus the time to operate and patch it; running two or more instances for availability multiplies the compute.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• Long-running application servers with a well-sized driver or framework pool may not need any proxy.
• You need SQL-aware read/write splitting and failover in the middleware: see PgBouncer vs Pgpool-II.
• A single PgBouncer process is CPU-bound on a large self-managed fleet: see Odyssey vs PgBouncer.
• Connection limits are a symptom of the wrong engine choice: compare Aurora PostgreSQL vs RDS PostgreSQL and Amazon RDS vs Amazon Aurora.

Final recommendation

Frequently asked questions

Sources

• Amazon RDS User Guide: Amazon RDS Proxy (quotas and limitations)
• Amazon RDS User Guide: Avoiding pinning an RDS Proxy
• Amazon RDS User Guide: Planning where to use RDS Proxy
• Amazon RDS Proxy pricing
• AWS price data: RDS Proxy (USD)
• Amazon RDS FAQs (RDS Proxy)
• AWS Database Blog: Fast switchovers with PgBouncer on RDS Multi-AZ DB clusters
• PgBouncer features and pooling modes
• PgBouncer configuration reference
• PgBouncer changelog

Checked November 2026.

How we research comparisons: our editorial method.