X_DB_POOL_EXHAUSTED
Means
no connection was available
Typical cause
SQLSTATE 53300 from the server, or the local pool answering nothing inside acquireTimeoutMs, for a plain statement as for a transaction (As of 2026-11-02) — deliberately one code, because to a caller both mean "there was no connection for this unit of work" and a second code would split one runbook in two. Refused rather than queued forever: a hang makes /readyz join the queue, the kubelet kills the pod, and the next pod inherits the same saturated database
Fix
set DATABASE_POOL_MAX below max_connections / replicas (per-role default: POOL_PROFILES), or cut the replica count