Database connection pool with recovery strategy

Without a connection pool, applications create a new database connection for every request — a pattern that fails catastrophically under load. At moderate traffic, the database server exhausts its connection limit and begins rejecting connections, producing 500 errors for all users simultaneously. CWE-400 (uncontrolled resource consumption) applies directly. ISO 25010 reliability.fault-tolerance requires resource management that prevents single-request failures from cascading into service-wide outages; unmanaged connection creation is one of the most common causes of that cascade in vibe-coded applications.

Configure a connection pool with explicit max, min, and idleTimeoutMillis settings. For Prisma with PlanetScale or Supabase, set connection_limit in the connection string.

// lib/db.ts — pg connection pool
import { Pool } from 'pg'

export const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10,
  min: 2,
  idleTimeoutMillis: 30_000,
  connectionTimeoutMillis: 2_000,
})

pool.on('error', (err) => {
  logger.error({ err }, 'Idle database client error')
})

For Prisma, append ?connection_limit=10&pool_timeout=10 to DATABASE_URL. Serverless environments (Vercel, AWS Lambda) should use PgBouncer or Supabase's connection pooler — each function invocation cannot hold a persistent pool.