The real serverless compute to database connection problem, solved
By Steven Van ·
Vercel explains why suspended serverless functions leak database connections and how Fluid Compute's waitUntil and attachDatabasePool fix it.
Vercel is pushing back on a common claim that serverless compute needs more database connections than other models. The number of concurrent connections needed depends only on concurrent requests, and the math works out the same whether you're running one big server or a thousand Lambda instances. The real problem, according to Vercel's writeup, is that a suspended serverless function can't fire its idle connection timer, so the pool client stays open and "leaks" until the instance is eventually deleted or the pooler times it out. That matters most on plans with tight connection limits, such as Supabase's free tier, which caps the pooler at 200 connections, and it gets worse on deploys, when every old function instance suspends at once and leaks until it times out.
Vercel says its Fluid Compute model can close idle connections before suspension using its waitUntil feature, which keeps a function alive just long enough to finish that work. Developers using the pg Pool don't need to implement this themselves: adding attachDatabasePool from @vercel/functions after configuring the pool handles it in one line. Vercel notes the added alive time costs little under Active CPU Pricing, since waiting for the idle timer to fire uses no CPU time.
Vercel's recommended practices for connection pools:
- Set a relatively low idle timeout, such as 5 seconds, so idle connections release quickly when traffic drops.
- Define connection pools in the global scope so they're shared across requests instead of recreated.
- Don't set the maximum pool size to 1: it doesn't reduce total connections on Lambda and limits concurrency on Fluid Compute and serverful setups.
