# SQL pushdown

> SQL pushdown means a dashboard sends its queries to run inside your database or warehouse and receives only the result rows, rather than copying your data.

Canonical: https://dvt.dev/glossary/sql-pushdown/

SQL pushdown is the practice of sending a dashboard's queries to run inside the source database or warehouse, so only the result rows travel back to the dashboard tool and the underlying data is never copied elsewhere.

The alternative is extraction: copying tables into the BI tool's own store on a schedule, then querying the copy. Extraction creates a second place your data lives, a second set of access rules to keep in sync, and a lag between what the warehouse says and what the dashboard shows.

## How it works in dvt

dvt pushes each [panel](https://dvt.dev/glossary/dashboard-panel)'s query down to the source named by its [connection](https://dvt.dev/glossary/connection-as-code) at view time. On Snowflake, BigQuery, and Postgres the SQL runs on your own compute, under the credentials the connection uses, and appears in your own query or job history. dvt receives the aggregated rows a chart needs and renders them.

Two consequences follow. First, the dashboard is current: numbers come from the warehouse at view time, not from an extract. Second, access stays where you already manage it. An agent building a dashboard inherits exactly the access the connection's credentials have, so your warehouse grants, IAM roles, and row-level policies keep deciding what can be read. For spreadsheets, dvt fetches the live [Google Sheet](https://dvt.dev/solutions/google-sheets-dashboards) fresh on each query and discards it afterward, so nothing is stored in a second database.

## Related terms

- [Connection as code](https://dvt.dev/glossary/connection-as-code)
- [Semantic layer and skills](https://dvt.dev/glossary/semantic-layer)
- [Agent-built dashboard](https://dvt.dev/glossary/agent-built-dashboard)
- [Dashboards as code, the dvt implementation](https://dvt.dev/solutions/dashboards-as-code)