PgBouncer vs RDS Proxy: what connection pooling actually costs

Connection pooling is usually sold as a reliability feature: it stops a bursty application from exhausting the database's connection slots. That framing hides the more interesting story. Every idle PostgreSQL connection holds a backend process and its share of work_mem, so a database sized to survive 800 concurrent connections is a database sized mostly for connection overhead, not for query work. Pooling lets you buy the smaller instance, and the smaller instance is where the savings live.

What each option bills

Note the shape of the RDS Proxy meter: it scales with the size of the database, not with the traffic through the proxy. That is counterintuitive but important. If you succeed at pooling and shrink the database, the proxy bill shrinks with it. If you keep the database oversized, you pay the proxy fee on top of the waste you were trying to eliminate.

The saving that matters is the instance step-down

Memory is the binding constraint for a connection-heavy PostgreSQL workload. A conservative planning figure is 5 to 10 MB of resident memory per idle connection once you include the backend process, catalog caches, and per-connection buffers. At 600 connections that is 3 to 6 GB doing nothing but holding sockets open, before a single query runs. Add work_mem allocated per sort or hash node and the number climbs.

Pool those 600 client connections down to 40 server connections and the memory pressure largely disappears. That is what lets a team move from a db.m5.2xlarge (8 vCPU, 32 GB, $0.712 per hour on-demand in us-east-1, roughly $520 per month) to a db.m5.xlarge (4 vCPU, 16 GB, $0.356 per hour, roughly $260 per month). The step-down saves about $260 per month. Against that, the RDS Proxy fee on the smaller instance is 4 x $0.015 x 730, about $43.80. Net saving: roughly $216 per month on a single database, before any reserved-instance discount compounds it.

Where the two options genuinely differ

RDS Proxy is multi-AZ by default, handles IAM authentication and Secrets Manager rotation, and preserves connections across a failover, which can cut failover-visible downtime meaningfully. You pay for that in the vCPU-hour meter and in a small added latency hop. PgBouncer is faster and cheaper but it is now a component you own: you size it, monitor it, patch it, and make it highly available yourself. Running one PgBouncer instance in front of a multi-AZ database quietly converts your highly available database into a single-point-of-failure architecture, which is a cost you only discover during an incident.

There is also a functional difference that affects cost indirectly. PgBouncer in transaction pooling mode gives the highest connection multiplexing ratio but forbids session-level features such as prepared statements held across transactions, advisory locks, and temporary tables. If your ORM depends on those, you end up in session pooling mode, where the multiplexing ratio collapses toward 1:1 and the instance step-down you were counting on never materializes. Verify the mode your application can actually tolerate before you write the saving into a budget.

A worked comparison

The $32 monthly gap between the two pooling options is not a serious decision input for most teams. The $216 gap between pooling and not pooling is. Pick the proxy that fits your operational appetite, then spend the effort on actually shrinking the instance, because a proxy you deploy without resizing the database is pure added cost.

Serverless changes the arithmetic

On Aurora Serverless v2, RDS Proxy bills a minimum of 8 vCPUs regardless of how small the cluster scales, which is 8 x $0.015 x 730, about $87.60 per month. If your serverless cluster floors at 0.5 ACU (about $43.80 per month at $0.12 per ACU-hour), the proxy costs twice the database. In that configuration a self-hosted pooler, or the built-in pooling in your application framework, is usually the better call.

Price the database and the proxy together from Terraform before you merge, because the two meters move in opposite directions and only the combined number tells you whether pooling paid. Compare instance families and proxy configurations against the resource catalog, and read the broader connection pooling cost picture for context.

FAQ

What to do next

See what pooling saves before you deploy it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.