PostgreSQL 16 connection pooling best practices for high-throughput apps?

hey folks, scaling up a production system and hitting connection limits on our PostgreSQL 16 instance. currently running about 8k requests/sec and we're maxing out at ~400 connections before things get sluggish.

right now we're using pgBouncer in transaction mode, but i'm seeing some overhead. should i switch to pgPool2 instead, or is there a smarter way to configure pgBouncer?

also curious if anyone's using connection pooling at the application level (like HikariCP for Java) and if that's actually better than a separate pooler. we're running on Vultr bare metal with 16GB RAM.

what's your setup look like?

At 8k req/sec, you're hitting diminishing returns with pure pgBouncer tuning. Instead of switching poolers, I'd actually recommend a hybrid approach: keep pgBouncer in statement mode (not transaction mode) for better connection reuse, then layer in application-level pooling like HikariCP with a smaller pool size (~20-30 connections). This way you get the best of both worlds—pgBouncer handles bursty traffic, your app maintains warm connections.

Also check your default_pool_size and reserve_pool_size settings in pgBouncer. Most people set them way too high. For your case, try default_pool_size = 25 and reserve_pool_size = 5, then monitor. https://www.pgbouncer.org/ has solid tuning docs.

One more thing—if you're not already, query the actual wait times with SHOW POOL_STATS in pgBouncer. That'll tell you if you're actually connection-limited or if it's something else (slow queries, locks, etc).

ah good point on statement mode, didn't realize the overhead difference was that significant. the hybrid approach makes sense—I'll test that out first before considering a full migration. thanks for the detailed breakdown!