db-connection-pooling (M15)

Connection exhaustion is a top cause of production outages and a pure Performance & Scale (axis performance) concern. Feeds relational Pooling w10 (and the Conexión category in every NoSQL profile). The dominant modern failure is serverless functions opening one direct connection each and saturating the backend.

What it checks

1. Serverless + direct Postgres — a function/edge runtime (Vercel/Lambda/Cloudflare/Netlify) connecting directly to Postgres with no pooler. Each cold start opens a connection; concurrency spikes blow past max_connections. Recommend a transaction-mode pooler or a serverless driver (Neon/@neondatabase/serverless, Supabase pooler, PlanetScale HTTP).
2. Transaction-mode pooler misuse — using a transaction-pooling endpoint (PgBouncer transaction mode, Supabase port 6543) while relying on session features it breaks: server-side prepared statements, SET/session GUCs, LISTEN/NOTIFY, advisory-session locks.
3. Pool sizing — application pool max × instance count exceeding backend max_connections, or a pool so small it serializes requests.