Choosing between enlarging TypeORM connection pool and removing request-scoped QueryRunner for bursty traffic

Goal

Identify the primary cause of intermittent connection pool exhaustion when a NestJS application using @nestjs/typeorm experiences bursty traffic.

Constraints / Uncertainty

The exhaustion could be caused by request‑scoped providers or per‑request QueryRunner instances that retain a checkout connection until the request finishes, making latency outliers indicative of held connections. Alternatively, the underlying driver pool may simply be too small for the concurrent checkout rate, pointing to total concurrency or database max_connections as the limiting factor. Distinguishing these requires correlating timeout events with request latency histograms and pool‑level metrics, which NestJS interceptors do not expose by default.

Open questions

• Does increasing the TypeORM driver pool size reduce checkout timeout errors without altering the distribution of request latency outliers?
• When request‑scoped QueryRunner usage is removed while keeping the pool size constant, do timeout spikes disappear and latency histograms shift?
• Can driver‑level pool diagnostics (e.g., active/idle/waiting counts) differentiate between timeouts caused by checkout queuing versus server‑side rejections?