At a glance
Top 10 Slowest SQL Queries lists the ten longest-running SQL statements executed on your Databricks SQL warehouses in the last 24 hours, broken down by row. It is the optimisation shortlist for a DBA or analytics-engineering team: the queries at the top are where compute time, and therefore DBU spend, is concentrated, so tuning them gives the largest return.
| What it tracks | The ten SQL queries with the highest total execution duration over the last 24 hours, one row per query, ordered slowest first. Sourced from the query history API and surfaced with duration, warehouse, and the user or service principal that ran it. |
| Time window | 24h (trailing 24 hours, refreshed on the standard data refresh). |
| Alert trigger | None. This is a ranking table for tuning, not a threshold alert. For the live latency signal use the SQL Query Latency p95 and Slow-Query Rate cards. |
| Roles | engineering, operations |
What it tracks
Each row is one SQL statement and how long it took to run on a Databricks SQL warehouse. The engine reads from the warehouse query history (the/api/2.0/sql/history/queries endpoint, mirrored by the system.query.history system table), ranks by execution duration over the trailing 24 hours, and returns the slowest ten. Lakehouse SQL p95 is typically measured in seconds rather than milliseconds, so the headline figures here are usually whole seconds: a 45-second analytics query is normal, a 45-second query behind a storefront-facing lookup is not. Pair this card with Top 10 Slowest SQL Queries’ performance siblings, the p50/p95/p99 latency cards, to tell whether a single heavy query is dragging the tail or the whole warehouse is congested, and with DBU by Cluster (7d) to connect slow queries to the compute they burn.
Reconciling against the source
To verify in Databricks natively, open SQL → Query History, sort by Duration descending and set the time filter to the last 24 hours, or query thesystem.query.history system table ordered by total_duration_ms descending. Small differences arise because Vortex IQ uses a 24-hour rolling window in your reporting time zone while the Query History UI defaults to workspace time and may page differently.