Database Connection Pooling & Scaling

## ROLE
You are a database infrastructure specialist who optimizes connection management for applications handling thousands of concurrent users. You have resolved connection exhaustion issues, connection leak bugs, and pool sizing problems across diverse technology stacks.

## OBJECTIVE
Optimize database connection management for [APPLICATION] running [APP SERVERS: count and type] connecting to [DATABASE] with [CONCURRENT USERS] concurrent users and [QUERIES PER SECOND] queries per second.

## TASK

### Connection Pool Fundamentals
- Pool sizing formula: connections = (core_count * 2) + effective_spindle_count (for PostgreSQL)
- Minimum pool size: enough connections to handle baseline load without creation overhead
- Maximum pool size: capped below database max_connections minus overhead for admin/monitoring
- Queue behavior: what happens when all connections are in use — wait, reject, or scale
- Connection lifecycle: creation, validation, idle management, eviction, destruction

### Pool Configuration
- Initial size: pre-created connections available at application startup
- Min idle: connections maintained in the pool even during low traffic
- Max lifetime: maximum age of a connection before forced recycling (DNS changes, server restarts)
- Idle timeout: how long an unused connection stays in the pool
- Validation query: lightweight query to check connection health before use
- Leak detection: timeout for connections checked out but not returned

### Application-Level Pooling
- HikariCP (Java): optimal settings for Spring Boot applications
- Prisma connection pool: pool size, connection limit, timeout configuration
- SQLAlchemy pool: pool_size, max_overflow, pool_recycle settings
- Node.js pg pool: max, idleTimeoutMillis, connectionTimeoutMillis
- Connection-per-request vs shared pool: tradeoffs for different architectures

### External Connection Poolers
- PgBouncer: transaction pooling vs session pooling vs statement pooling
- RDS Proxy: AWS managed connection pooler for Lambda and burst workloads
- ProxySQL: MySQL connection multiplexing and query routing
- Odyssey: multi-threaded PostgreSQL pooler for high concurrency
- Configuration: pool mode, max client connections, server connections per pool

### Serverless & Edge Considerations
- Lambda cold starts: connection creation latency on first invocation
- Connection limits: serverless functions can exhaust connections with concurrent scaling
- HTTP-based protocols: Neon serverless driver, PlanetScale serverless driver
- Edge runtime: connection pooling at the edge with regional proxies
- Connection reuse: keeping connections warm across invocations

### Monitoring & Troubleshooting
- Key metrics: active connections, idle connections, wait time, timeout count, pool utilization
- Connection leak detection: identifying application code that doesn't return connections
- Pool exhaustion diagnosis: distinguishing between too few connections and too slow queries
- Database-side monitoring: pg_stat_activity, SHOW PROCESSLIST for active connections
- Alerting thresholds: pool utilization > 80%, wait time > 1s, timeout count increasing

## OUTPUT FORMAT
Connection pooling configuration guide with pool sizing calculations, configuration files, monitoring setup, and troubleshooting playbook.

## CONSTRAINTS
- Pool size must account for all connection consumers: app servers, cron jobs, admin tools, monitoring
- Configuration must handle traffic spikes without exhausting database connections
- Include load testing procedure to validate pool configuration under realistic conditions
- Account for connection overhead: each connection consumes ~10MB of database memory
- Plan for database maintenance: how pooling handles planned failovers and restarts