At a glance
Top 10 Slowest Queries ranks the ten query shapes that have cost the most time over the last 24 hours, broken down by row. It is the “which queries” companion to the slow-query rate: when the rate rises, this table names the specific statements responsible so you can go straight to the index, plan, or rewrite that will fix them.
What it tracks
This card lists the Top 10 Slowest Queries, broken down by row, over a rolling 24-hour window. Each row is a normalised query shape (parameters collapsed, soWHERE id = 1 and WHERE id = 2 count as one entry) with its key timing statistics: number of calls, mean execution time, total accumulated time, and typically the slowest single run. The ranking is by total time cost rather than by single-query duration, because a moderately slow query called millions of times can hurt the database more than one genuinely slow query run rarely. The data comes from the pg_stat_statements extension, which Supabase enables by default and which aggregates execution statistics per statement across the whole project, including queries arriving through PostgREST, the connection pooler, Edge Functions, and direct connections. This card carries no alert threshold; it is a diagnostic table you reach for when Slow-Query Rate % flags or when latency drifts and you need to know exactly where to optimise.
Reconciling against the source
Confirm directly in Postgres withSELECT query, calls, mean_exec_time, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;, or use the Supabase project Query Performance report, which surfaces the same pg_stat_statements ranking. Differences usually come down to window (this card is 24-hour; pg_stat_statements accumulates lifetime totals until a pg_stat_statements_reset()) and to ranking basis (total time here, which you can match by ordering on total_exec_time).