dbt show compiles a model, runs its query with a limit and prints the first rows. Nothing is created
or replaced in the warehouse, which makes it the quickest way to check a change before running the
model for real.
Copy and paste
dbt show -s customer_orders # the first 5 rows of the model's query
dbt show -s customer_orders --limit 20
dbt show -s customer_orders --output json # for scripts
dbt show --inline "select * from {{ ref('fct_orders') }} where status = 'returned'"The output:
Previewing node 'customer_orders':
| customer_id | name | orders | revenue |
| ----------- | ------ | ------ | ------- |
| 12 | Chiara | 1 | 30 |
| 10 | Anna | 2 | 170 |
| 11 | Ben | 2 | 125 |How it works
dbt compiles the model’s select, adds a limit and sends it to the warehouse. The models it reads from
must exist: dbt show does not build parents. In a fresh development schema, add
--defer --state prod-state to read them from production, as in
how to run only modified models.
The limit only cuts the result. The warehouse may still do most of the work of a heavy query, so a preview of a large aggregation costs nearly as much as running it.
The incremental model trap
On an incremental model, dbt show -s fct_orders runs the model’s query with the incremental filter
active, because the table already exists. Right after a run there are no new rows, and the preview is
empty:
Previewing node 'fct_orders':
| order_id | customer_id | order_date | status | amount | updated_at |
| -------- | ----------- | ---------- | ------ | ------ | ---------- |That is the batch the next run would add, not the content of the table. To look at the table, query it
with --inline:
dbt show --inline "select * from {{ ref('fct_orders') }} order by order_id" --limit 10–inline
--inline runs any query, with ref(), source() and macros resolved. It is handy for checking a
join or a duplicate count without opening the warehouse console:
dbt show --inline "select order_id, count(*) from {{ ref('fct_orders') }} group by 1 having count(*) > 1"Tested with dbt Core 1.12.
