PostgREST Request Rate (req/sec), Supabase

​

At a glance

This card plots how many requests per second PostgREST is serving over time. PostgREST is the auto-generated REST layer that fronts your Supabase database, so this is the throughput of the API your application actually calls. It is the load axis for every latency and error card in the connector: a latency spike means something very different depending on whether request rate spiked with it. For a platform or SRE team this line chart is the context everything else is read against. It tells you when your busy windows are, whether a slowdown is “more traffic” or “a regression”, and when capacity planning is overdue. It carries no fixed alert by design, throughput is neither good nor bad in isolation; it is the denominator that makes the other cards interpretable.

​

Calculation

req_per_sec = count(PostgREST requests in interval) / interval_seconds
plotted as a time series over the rolling window
no fixed alert: read as load context for the latency and error cards

1. It is the denominator for everything else. A rise in p95 latency with a matching rise in request rate is a capacity story (more load, slower responses). The same latency rise with a flat request rate is a regression story (the same load got slower, so something changed). You cannot tell the two apart without this card, which is why it sits in the same category as the latency gauges.
2. Shape matters more than the absolute number. What is “normal” varies hugely by project. The value of the time series is its pattern: the daily peaks and troughs, the weekly rhythm, the step changes after a launch. A sudden cliff to near zero (an outage or a broken deploy) and a sudden vertical wall (a traffic surge, a runaway client, a retry storm) are both far more informative than any single instantaneous reading.

​

Worked example

1. The load is real and abnormal. 980 req/sec at 15:10 is more than five times the usual evening peak, in the early afternoon. This is not a normal busy window; something is driving traffic far above pattern.
2. Latency and errors are now following the load. p95 has climbed from 72ms to 240ms and the 5xx rate has crossed 1%. Cross-referencing Supavisor Pool Saturation %, the pool is at 94%: the surge is exhausting connections, which is why latency and errors are rising together. This is a capacity story, not a code regression.
3. The cause is a client retry storm. The shape (a vertical wall rather than organic growth) plus the early-afternoon timing points at a misbehaving client. A recent mobile release shipped an aggressive retry loop that re-fires failed requests without backoff, so as latency rose the clients retried harder, driving the rate up further, the classic self-reinforcing storm.

Reading load vs regression from this card:
  - Latency up AND request rate up   -> capacity / load story
  - Latency up AND request rate flat -> regression (queries got slower)
  - Request rate up AND error rate up -> load is exceeding a limit
  - Request rate cliff to ~0          -> outage or broken deploy upstream

Confirm a retry storm:
  - request rate climbs super-linearly while unique clients stay flat
  - 5xx rate and request rate rise together (errors trigger more retries)
  - cross-check Supavisor saturation and the app's retry/backoff config

Mitigations, in order:
  1. Ship a client fix with exponential backoff and a retry cap.
  2. Rate-limit at the edge / API gateway to break the storm now.
  3. Move clients to the transaction-mode pooler and/or raise the tier
     pool size so legitimate load is not starved while you fix the client.

1. Request rate is the lens, not the verdict. It has no alert because throughput alone is neither good nor bad. Its job is to tell you which story a latency or error spike belongs to: more load, or the same load gone wrong.
2. Watch the shape. Organic growth ramps; a retry storm or runaway client makes a near-vertical wall; an outage makes a cliff. The shape of the line usually names the cause before any other card does.
3. A flat request rate during a latency spike is a smoking gun. It means traffic did not change but responses got slower, so the cause is inside your system (a slow query, a missing index, a pool problem), not your users.

​

Sibling cards

​

Reconciling against the source

In the Supabase dashboard, open Reports → API for the request-count and request-rate charts PostgREST records per route. The dashboard throughput chart and this card draw from the same request-log stream. Count requests yourself in the project’s log explorer: the api_logs / edge request logs hold one row per request, so a count over a fixed window divided by the window length reproduces the rate. To see how API throughput translates into database work, compare against Database Queries per Second (live) and pg_stat_statements calls; a single PostgREST request can fan out into several queries. The managed-service console exposes equivalent request-rate charts under the project’s observability section; confirm the chart’s interval matches the card’s before comparing instantaneous values.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre