At a glance
Postgres Query Latency p95 (ms) is the 95th-percentile execution time of statements run against your Supabase Postgres instance over the selected period. Ninety-five out of every hundred queries complete faster than this number; the slowest five percent take longer. It is the headline read on database responsiveness, and it climbs before users notice, so it is an early warning rather than a lagging one.A high p95 means the slow tail of your workload is dragging: missing indexes, lock contention, a bloated table, or a connection pool under pressure are the usual causes. The card pairs with the latency, slow-query, and pool-saturation siblings to localise the cause before it becomes a checkout-window problem.
What it tracks
The card reports Postgres Query Latency p95 (ms) for the selected period, sampled in real time on a rolling 5-minute window (RT/5m). The value is the p95 of statement execution time as seen by the database, not round-trip time from the client, so network and Supavisor pooling overhead are excluded. The alert fires when p95 sustains above 200ms, the point at which the slow tail starts to show up in user-facing requests. Roles: engineering, operations. Read it next to Slow Query Rate and Top 10 Slowest Queries when it climbs.
Reconciling against the source
Confirm the number against Supabase’s own tooling: enable thepg_stat_statements extension and query SELECT query, mean_exec_time, max_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC for per-statement timings, or open the Query Performance and Reports pages in the Supabase project dashboard for the managed-service view. Note that pg_stat_statements reports mean and max per statement rather than a true cross-statement percentile, so expect approximate, not exact, agreement with the card’s p95.