Connection Pool Proxy

Shielding the Database from Serverless Architectures.

The idea

PostgreSQL creates a heavy OS process for every single client connection. If you have 500 open connections, it runs out of memory. This used to be fine when you only had 5 Application Servers (5 x 50 connections = 250). But in Serverless (AWS Lambda, Vercel), you might have 1,000 Lambdas spin up instantly. They will flood the DB with 1,000 connections and crash it. A Connection Proxy (like PgBouncer) sits in the middle: it accepts 10,000 lightweight connections from Lambdas, but multiplexes them over just 50 heavyweight connections to the DB.

How it works (Transaction Multiplexing)

PgBouncer speaks the Postgres protocol. The Lambdas think they are connecting to a real database. Because most web requests spend 95% of their time idle (waiting on network, processing JSON, etc), PgBouncer only hands a REAL database connection to a Lambda for the exact milliseconds it takes to run a SQL transaction. Then it takes it back.

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

# App configuration WITH PgBouncer Proxy
# We just point the URL to the Proxy's port (6432)
# The application code doesn't change at all!
DATABASE_URL=postgres://user:pass@pgbouncer.prod:6432/mydb

Cost

Running a proxy in "Transaction Mode" breaks certain Postgres features. Because consecutive queries in the same Lambda might be routed to different underlying DB connections, you cannot use Session-level features (like Prepared Statements, Temporary Tables, or SET search_path). Your ORM must be configured to disable prepared statements.

Watch out for

• Proxy Bottleneck: While the proxy saves the database, the proxy itself runs on a server (often single-threaded). If you push 50,000 req/sec through PgBouncer, it will max out its own CPU. You may eventually need a fleet of proxies!