IBM Cloud Functions and Db2 on Cloud: Tuning Connection Pool Size for Concurrent Invocations

Confirmed Facts

Db2 on Cloud enforces a hard limit on concurrent connections per service instance; exceeding this limit returns SQLState 08004 'connection limit exceeded'.

Without a connection pool, each function activation opens a fresh Db2 connection that stays open until the activation ends, so the number of simultaneous Db2 connections tracks the function's concurrency.

Observed latency spikes (DSN0050I connection‑wait messages) occur when the number of concurrent activations exceeds the configured connection pool size.

The Functions pre‑warmed option (Enterprise plan) reduces cold‑start latency but does not affect the number of Db2 connections required per activation.

Likely Explanation

For typical workloads the goal is to keep the Db2 connection pool utilization in the 70‑80 % range. This provides headroom for short bursts while avoiding queueing when the pool is exhausted. Setting the pool max size to 80 % of the Db2 service‑plan limit, but never higher than the function's maxConcurrent value, yields the smallest latency under steady load.

Consequently, the ratio of Db2 maxConnections to Functions maxConcurrent that minimizes latency is approximately 1.25 when the function concurrency is the limiting factor (i.e., Db2 maxConnections ≈ 1.25 × Functions maxConcurrent). If the Db2 plan limit is lower than this value, the ratio will be < 1 and the pool size must be capped at the Db2 limit.

Enabling pre‑warmed containers does not change this ratio because each activation still needs its own Db2 connection from the pool; the feature only affects container start‑up time.

For burst traffic, tune the connection timeout to be slightly above the expected Db2 response time (e.g., 5‑10 s) and enable a limited retry mechanism (e.g., max 2 retries with exponential backoff). This prevents activations from waiting indefinitely while keeping queuing delay low.

Steps Needed for This Case

1. Determine the function's target maxConcurrent setting (from the manifest or Cloud Functions UI).
2. Obtain the Db2 on Cloud service plan's maximum allowed concurrent connections (service dashboard or CLI).
3. Calculate the connection pool max size: poolMax = Math.min(maxConcurrent, floor(0.8 × Db2 maxConnections)).
4. Configure the JDBC pool (e.g., HikariCP) with this poolMax, a modest minIdle (e.g., 2), and a connection timeout of 5‑10 s.
5. Package the pool configuration with the function code and redeploy.
6. Validate under load: monitor Db2 active connections (should stay < Db2 limit) and check function logs for connection‑wait or timeout messages.

Missing Diagnostic Detail

To finalize the pool size, please provide the Db2 on Cloud service plan's maximum allowed concurrent connections. Without this value the exact pool size cannot be computed.