Record the database connection allowance, web and worker process counts, and other applications using the same server. Reserve capacity for maintenance and recovery.

1. Estimate the maximum combined connections from every process, including pool overflow and background tasks. Check the actual pool library’s semantics.

2. Measure query duration and how long requests retain a connection. Avoid holding a transaction open while waiting for a slow external API when the design can release it sooner.

3. Set finite acquisition and connection timeouts so overload produces a controlled failure instead of an unlimited backlog.

4. Adjust pool size and application concurrency together through a representative load test. More connections can increase database contention rather than improve throughput.

5. Monitor active, idle and waiting connections after deployment and during scheduled work. Revisit the budget when adding workers or another application.

Suppose a database allows 60 connections and you reserve 15 for administration and other services. Four web processes, each with a SQLAlchemy QueuePool of five connections and two overflow connections, can request up to 28 connections between them.

Web processes: 4 x (pool_size 5 + max_overflow 2) = 28
Background workers: 2 x (pool_size 4 + max_overflow 0) = 8
Planned application maximum: 28 + 8 = 36
Usable connection budget: 60 - 15 = 45

These numbers are a planning example, not Nabtech plan limits. Count every process that creates its own pool. A rolling deployment can temporarily double process counts, so either reserve room for that overlap or stage the replacement. Give pool acquisition a finite timeout and inspect long-held transactions before increasing capacity.

Expected result: The application stays within its real account allowance during traffic peaks and deployment transitions, while connection waiting and database latency remain acceptable.

Confirm peak usage remains within the planned capacity and requests do not spend excessive time waiting for a pool slot. Check database latency as well as application latency.

If the pool fills while database activity is low, look for leaked or long-held connections. Increasing the pool can delay the symptom while consuming more resources.

• Investigating Django database connection exhaustion
• Managing FastAPI lifespan resources and database pools
• Measuring application latency by dependency
• Choosing a health check that reflects user-visible failure

• PostgreSQL connection settings
• Django database connections

• SQLAlchemy connection pooling