At a glance
Query Latency p50 (ms) is the median query execution time: half of all statements finished faster than this number, half slower. It is the “typical query” view, the experience the average request gets. Read it next to the p95 and p99 cards: when p50 holds steady but the upper percentiles climb, the problem is a slow subset, not a broad slowdown.
What it tracks
The card reports the 50th-percentile (median) execution time across statements in the window, refreshed in real time and smoothed over a rolling five-minute window (RT/5m). It is computed from per-statement timing in pg_stat_statements (the call-weighted mean_exec_time distribution), or from log-derived durations where log_min_duration_statement is enabled. Like the other latency cards it measures server-side execution time only: it excludes time a statement spends waiting for a connection slot and excludes network round-trip. The median is deliberately resistant to outliers, so a single pathological query barely moves it, which is exactly why p50 answers “how fast is a normal query” while the p95 and p99 cards answer “how bad is the tail”. There is no alert on this card; the actionable latency thresholds live on Query Latency p95 (ms) (alerts above 200ms) and Query Latency p99 (ms) (alerts above 500ms).
Reconciling against the source
Reproduce the basis in PostgreSQL withSELECT query, calls, mean_exec_time FROM pg_stat_statements ORDER BY calls DESC; (requires the pg_stat_statements extension), or read exact durations by setting log_min_duration_statement low and reading the logged statement times. On a managed service, compare against AWS RDS Performance Insights, Google Cloud SQL Query Insights, or Azure Database for PostgreSQL Query Store, noting that those consoles often headline average latency, which sits below the median on a tailed workload.