Connection Pooling Proxy (Gateway)

Standing between thousands of microservices and one fragile database.

The idea

A Postgres database usually handles at most ~500 concurrent connections before memory and CPU context-switching choke it to death. But what if you have 100 Serverless Functions (like AWS Lambda), and each one opens 10 connections? That's 1,000 connections—the DB crashes! The solution is a Proxy Gateway (like PgBouncer). The Lambdas connect to the Proxy (which easily handles 10,000 idle connections), and the Proxy funnels their queries into a tiny pool of just 50 real connections to the DB.

How it works (PgBouncer)

The proxy pretends to be the database. Your application doesn't even know it's not talking directly to Postgres. You just change the port in your database URL. The proxy multiplexes the traffic, holding real DB connections open permanently, and handing them out to clients for the duration of a single transaction.

# App configuration WITHOUT a proxy
DATABASE_URL=postgres://user:pass@db-main.prod:5432/mydb

# App configuration WITH PgBouncer Proxy
# The app logic requires ZERO code changes. 
# We just point it to the Proxy's port (6432)
DATABASE_URL=postgres://user:pass@pgbouncer.prod:6432/mydb

Cost

A Proxy introduces a small network hop penalty (a few milliseconds). It also complicates Session State. If your proxy operates in "Transaction Mode" (the most common and scalable), you cannot use Postgres features that span across multiple transactions, like prepared statements or temporary tables, because consecutive transactions might be routed to completely different real connections.

Watch out for

• Serverless architectures: If you use AWS Lambda or Vercel Edge Functions with a relational database, a proxy (like AWS RDS Proxy or Supabase's PgBouncer) is mandatory. Without it, every Lambda cold start opens a new TCP connection, instantly exhausting the database limits.