Pattern: Database connection management in serverless

Serverless functions create a new database connection on every invocation, overwhelming the database with connections and adding latency.

Connection management strategies for serverless:

1. Connection reuse (same instance):

# Initialize outside handler, reuse across invocations
import psycopg2
conn = None

def handler(event, context):
global conn
if conn is None or conn.closed:
conn = psycopg2.connect(DB_URL)
# Use conn... (reused if same Lambda instance)

1. Connection pooler (PgBouncer / RDS Proxy):

# Place a connection pooler between Lambda and database
# Lambda connects to pooler, pooler manages DB connections
# RDS Proxy: managed, no setup
# PgBouncer: self-hosted, more control

1. Serverless-friendly drivers:

# @neondatabase/serverless - HTTP-based PG driver
# @planetscale/database - HTTP-based MySQL
# Prisma with connection pooling
# Drizzle ORM with serverless adapters

1. Connection limits:

# Lambda: max_connections = concurrent_lambdas * connections_per_lambda
# If 100 concurrent Lambdas, each with 1 connection = 100 DB connections
# PostgreSQL default max_connections = 100 (too low!)
# Fix: use RDS Proxy or increase max_connections

1. HTTP-based alternatives:

# Supabase, Neon, PlanetScale offer HTTP APIs
# No persistent connections needed
# Higher latency per query but no connection overhead

Serverless connection management is the #1 operational challenge. Without pooling, each function invocation can create a new connection, exhausting database limits.