If you know dbt, you already know DRE
dbt changed how data teams work. Transformations became SQL in git: reviewed, tested, versioned and run by a tool instead of by hand. We think dbt is an excellent tool, and DRE borrows its experience on purpose, for the part dbt leaves to others: the reports people receive.
Two tools, one workflow
dbt builds the data
It transforms raw data into tested, documented tables and views inside your warehouse.
DRE delivers it
It reads those tables and produces the exact file someone asked for: a workbook with formats and totals, a fixed-width file, a CSV extract. Then it sends it to an inbox, an SFTP server, a bucket or a Slack channel.
DRE never builds tables or models, and dbt doesn’t write Excel workbooks or send files. That’s why they fit together rather than compete: dbt is where your data is made, DRE is the last mile.
What will feel familiar
| Idea | In dbt | In DRE |
|---|---|---|
| A project of SQL and YAML in git | dbt_project.yml, models/ | dre_project.yml, reports/ |
| Jinja in SQL, with macros | macros/, var(), env_var() | macros/, var(), env_var() |
| Reusing SQL | ref('model') points at a built model | ref('file') reuses another .sql file as a subquery, or a lookup as a table |
| Declared sources | sources: and source() | The same format: a dbt sources.yml pastes in unchanged |
| Small reference data as files | Seeds | Lookups (csv, xlsx, json, yml) |
| Folder config | +tags, +materialized… | +tags, +output, +profile, +vars |
| Connections per environment | profiles.yml, targets, --target | profiles.yml, targets, --target |
| Selecting what to run | -s tag:finance, paths | -s tag:finance, folders, source: |
| Compiled SQL and artifacts | target/, manifest.json, run_results.json | target/, a manifest, run_results.json |
| Macro packages | dbt_utils, adapter.dispatch() | dre_utils, dispatch() |
Some ideas share a name but not every detail; DRE’s ref(), for example, reuses SQL rather than pointing at a built model. The concepts page has the exact rules.
Using them together
Declare the tables dbt builds as sources (in dbt’s own format, so you can copy the file across), then select from them in a report. The workbook below goes to finance on the 1st of every month, from the same git repository habits your dbt project already has.
version: 2
sources:
- name: marts
schema: analytics
tables:
- name: fct_revenueselect region, sum(net) as net
from {{ source('marts', 'fct_revenue') }}
where month = '{{ run.date.prev_month.start.date }}'
group by regionqueries:
- {query: revenue, tab_name: Revenue}
output:
format: xlsx
columns:
net: {format: "#,##0.00"}
destination:
profile: mail
to: finance@example.com
subject: "Revenue {{ run.date.prev_month.start.date }}"Questions dbt users ask
Is DRE a dbt plugin or adapter?
No. DRE is a separate open-source tool with its own code and file formats. It reads the tables dbt builds through an ordinary database connection, so it works with dbt Core and dbt Cloud alike.
Do I need dbt to use DRE?
No. DRE runs SQL against any supported database, whether or not dbt built the tables. If you do use dbt, DRE fits next to it: same habits, same git workflow.
Can DRE read my dbt models?
Yes. A dbt model is a table or view in your warehouse, so a DRE query can select from it directly or through a declared source().
Why open source
dbt showed what a generous open-source tool can do for a whole profession. DRE is our way of giving something back: free under GPL-3.0, built in the open, for the reporting work every data team still does by hand.