Database connection pools

Canonical guidance

• treat sql.DB as a pool, not a single connection
• configure pool limits intentionally
• reuse one long-lived handle per database configuration

Use when

• API servers with SQL backends
• background workers hitting a database
• diagnosing saturation or connection churn

Avoid

• opening a fresh sql.DB per request
• unlimited concurrency against a small database
• pool tuning without observing workload and downstream limits

Preferred pattern

• create the pool at startup, validate connectivity, and reuse it for the process lifetime

Anti-pattern

• setting huge pool sizes because request concurrency is high

Explanation: This is tempting because bigger pools look like throughput, but they can simply move overload onto the database.

Why

• pool settings are part of resource management and tail-latency control