I'm frustrated by connection pooling problems in PostgreSQL. What are people doing instead?

A lot of people are moving away from “lots of app servers each holding many long-lived Postgres connections” and toward one of these patterns:

1. External connection poolers

   • PgBouncer is the common answer.
   • It sits between your app and Postgres and keeps a smaller set of server connections open.
   • Best when your app creates many short-lived client connections.
   • Common pooling modes:
     • Transaction pooling: most efficient, but some session features don’t work well.
     • Session pooling: more compatible, less efficient.
   • This is often the first thing people try instead of relying on app-level pooling.

2. Fewer direct connections, more async work

   • Some teams reduce active DB connection demand by:
     • using job queues,
     • batching writes,
     • reading from caches,
     • pushing non-critical work out of request paths.
   • The idea is to make the database less “chatty” so connection count matters less.

3. Serverless / managed pooling layers

   • In cloud setups, people often use managed proxies or pooling services:
     • AWS RDS Proxy
     • Cloud SQL Auth Proxy / connector patterns
     • Neon/Supabase-style pooling setups
   • These are basically “pooling, but managed for you.”

4. One connection pool per process, not per request

   • If the issue is app code creating connections repeatedly, the fix is often just:
     • initialize a pool at startup,
     • reuse it across requests,
     • keep pool size small and intentional.
   • This is still pooling, but done correctly at the app layer.

5. Sharding / splitting workloads

   • At larger scales, people sometimes reduce connection pressure by:
     • splitting read and write traffic,
     • using replicas,
     • sharding tenants or workloads.
   • This doesn’t remove pooling, but it avoids one giant connection bottleneck.

6. Alternative databases / architectures

   • Some teams switch away from a single heavily shared Postgres instance when connection management becomes the main pain point.
   • Examples:
     • distributed SQL systems,
     • event-driven architectures,
     • document stores for certain workloads.
   • This is usually a bigger architectural move, not the first fix.

Practical reality

Most people are not abandoning pooling entirely. They’re usually doing one of:

• PgBouncer in front of Postgres
• small app-side pools
• managed proxy/pooling services

If you want, I can also give you:

• a “what to use when” decision table, or
• a recommended setup for Node/Python/Rails/Go.