CRDB Pool Saturation vs Traffic Burst, CockroachDB

​

At a glance

CRDB Pool Saturation vs Traffic Burst lays your CockroachDB connection-pool saturation alongside front-of-store traffic, row by row, over a rolling 15-minute window. It answers the one question a DBA cannot answer from the database alone: “is the pool filling up because real shoppers arrived, or because something is leaking sessions?” When saturation climbs in lockstep with a genuine traffic burst, the cluster is doing its job and you scale. When saturation climbs while traffic is flat, you have a connection leak or a runaway client pool, and adding capacity just delays the wall. This is the card that stops a team raising the connection ceiling against a leak.

​

Calculation

row[t] = {
  bucket:       t  (rolling 15m window, ~1-minute buckets)
  saturation%:  (open SQL connections at t / configured connection ceiling) * 100
  traffic:      front-end sessions or requests per minute at t (joined connector)
  correlated?:  saturation breach AND traffic elevated in the same bucket
}

​

Worked example

1. Confirm the correlation is tight. Because saturation tracks traffic almost linearly, this is real demand. Contrast with the alternative below, where the same 94% would mean a leak.
2. Scale the right lever. Real demand means widen capacity: raise server.max_connections_per_gateway if node memory allows (Memory Usage % is comfortable here), add a gateway node, or, structurally, front the cluster with a connection pooler so app threads multiplex onto a bounded server pool.
3. Watch the downstream pulse. Cross-read Statement Latency p95 (ms): if it has not moved, the pool is full but not yet hurting users, and you have a few minutes to act cleanly.

Why the comparison matters financially:
  - Real burst at 94%: scaling now keeps a flash sale converting; doing nothing risks refused checkouts.
  - Leak at 96% with flat traffic: scaling wastes money AND hides the bug; the wall returns.
  - Same saturation number, opposite correct action. Only the traffic pairing tells them apart.

1. Saturation alone is ambiguous; saturation paired with traffic is a decision. 94% means “scale” or “find the leak” depending entirely on whether traffic moved with it.
2. A correlated breach is a capacity win, not a failure. It means the sale drove real load. Plan capacity ahead of known peaks so you are not scaling reactively at 94%.
3. The anti-correlated row is the one to fear. Saturation up, traffic flat, is the leak signature, and it is the case a database-only view would misread as “we need more capacity”.

​

Sibling cards

​

Reconciling against the source

DB Console SQL dashboard (“Open SQL Sessions” panel) for the live sql.conns series per node, the database side of this card. SELECT count(*) FROM crdb_internal.cluster_sessions; for the exact open-connection count at a moment. SHOW CLUSTER SETTING server.max_connections_per_gateway; to confirm the ceiling the saturation percentage divides by. CockroachDB Cloud Metrics tab plots the same connection series; the cluster Overview shows the plan connection limit. The traffic side has no CockroachDB equivalent: confirm it against your storefront or analytics connector’s own session / request reports.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre