PostgREST API Latency p95 (ms), Supabase

​

At a glance

This card reports the 95th-percentile response time of requests served by PostgREST, the auto-generated REST layer that fronts your Supabase database. It is Supabase-distinctive: PostgREST is what your application code actually calls, so its p95 is the closest server-side proxy you have for how fast your API feels to real clients. The p95 means 95% of requests completed at or below this number in the window, and 5% were slower. It catches the slow tail that an average hides, while staying robust against the handful of pathological outliers that distort p99. For a platform or SRE team this is the headline latency gauge: when it bends upward, the application gets slower for a meaningful slice of users before anything has actually broken.

​

Calculation

p95 = the latency value at the 95th percentile of all PostgREST
      request durations in the window
fire when: p95 > 200ms (sustained, OLTP API profile)

1. Percentile, not average. A mean is dragged down by the many fast cache-hit reads and hides a slow minority. The p95 deliberately surfaces the slow tail: it is the experience of the unluckiest 1 in 20 requests. A p95 of 180ms with a mean of 35ms is normal; it means most calls are quick and a tail of heavier queries sits behind them.
2. PostgREST latency is mostly Postgres latency plus pool wait. PostgREST itself is thin. When this card rises, the cause is almost always downstream: a slow query, a missing index, lock contention, or, very commonly on Supabase tiers, time spent waiting for a free connection in the Supavisor pool. The pooler wait is invisible in the SQL plan but very visible here.

​

Worked example

1. The median barely moved, the tail blew out. p50 went 24ms to 31ms (a normal load nudge) while p95 jumped from 68ms to 246ms. That shape (stable median, exploding tail) is the signature of contention, not of every query getting uniformly slower. Something is making a minority of requests wait.
2. Check the pooler before blaming the queries. Cross-reference Supavisor Pool Saturation %; it has climbed to 96%. The surge opened more concurrent requests than the tier’s pool can serve at once, so a slice of requests now queue for a connection. The added latency is pool wait, not slow SQL.
3. The database itself is fine. Postgres Query Latency p95 (ms) is steady at 19ms. This confirms the queries are fast once they run; the lost time is in front of them, queueing for a connection.

Triage path for a tail-only p95 breach:
  1. Pool wait (most common on Free/Pro under burst):
     - Supavisor Pool Saturation high -> requests queue for a connection.
     - Fix: move clients to the transaction-mode pooler (port 6543),
       reduce per-request connection lifetime, or raise the tier's pool size.
  2. Slow query (if Postgres p95 also rose):
     - Find it in pg_stat_statements ORDER BY mean_exec_time DESC.
     - EXPLAIN (ANALYZE, BUFFERS) the offender; add the missing index.
  3. Lock contention (if Deadlocks or lock waits also rose):
     - Check pg_stat_activity for wait_event_type = 'Lock'.

Confirm pool-wait hypothesis:
  SELECT count(*) AS waiting
  FROM pg_stat_activity
  WHERE wait_event_type = 'Client' OR state = 'idle in transaction';
  -- plus the Supavisor saturation card trending alongside the p95 spike.

1. Read the shape, not just the number. A tail-only spike (stable median, exploding p95) means contention or queueing; a whole-distribution shift (median and p95 rise together) means the queries themselves got slower. They have different fixes.
2. On Supabase, pool wait is the usual hidden cost. Tier-bound Supavisor caps mean a traffic burst exhausts connections fast, and the wait shows up here, not in the SQL plan. Always check pool saturation before re-indexing.
3. 200ms is an OLTP API threshold, not a universal law. Endpoints that aggregate or paginate large result sets will legitimately run slower. Set the threshold per workload in the Sensitivity tab rather than chasing one global number.

​

Sibling cards

​

Reconciling against the source

In the Supabase dashboard, open Reports → API (and the Logs → API / Edge explorer) for the request-duration distribution PostgREST records per route. The dashboard charts and this card draw from the same request-log stream. Query the logs directly with the project’s log explorer: the api_logs / edge request logs expose per-request execution_time / response duration, which you can percentile yourself over a matching window. To separate API overhead from database time, compare against pg_stat_statements (mean_exec_time, max_exec_time) for the underlying queries. If Postgres is fast but PostgREST is slow, the gap is pool wait or serialisation, not the SQL. The managed-service console exposes the same metric under the project’s observability charts; confirm the chart’s percentile and window match the card before assuming a divergence.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre