Connection Pooling: PgBouncer vs Pgcat vs RDS Proxy

Connection pooling is foundational at any scale. PgBouncer is the default; alternatives have specific advantages.

Why pooling

Without pooling: every app connection = Postgres process.

With pooling: thousands of app connections multiplexed onto dozens of DB connections.

Three options

• PgBouncer: classic; battle-tested; single-threaded.
• Pgcat: modern Rust rewrite; multi-threaded; load balancer features.
• RDS Proxy: AWS managed; tied to RDS.

Four-criteria comparison

PgBouncer: simple; reliable; less feature-rich.

Pgcat: faster; sharding-ready; less mature.

RDS Proxy: zero ops; AWS-only; managed lock-in.

When to migrate

Migrate from PgBouncer to Pgcat when: you need sharding routing or multi-threading.

Migrate from PgBouncer to RDS Proxy when: you’re fully on RDS and want zero-ops.

Antipatterns

• No pooling at scale. Postgres OOM at high connection count.
• Pooling without metrics. Pool-exhaustion incidents undiagnosed.
• RDS Proxy outside RDS. Wrong tool.

What to do this week

Three moves. (1) Apply this pattern to your most-loaded table. (2) Measure query latency / write throughput before/after. (3) Document the win and the constraint so the next refactor inherits the knowledge.