dbt

dbt models run inside Thunderduck: you connect a Git repository, and runs execute in an isolated container with your catalogs attached.

Connect a repository

Transformations → Repositories → Connect. Give it the repository URL, a branch, and a token with read access. Thunderduck clones it per run — nothing is kept between runs except the artifacts.

What models can reference

Every catalog, with the usual addressing:

-- models/orders_daily.sql
SELECT date_trunc('day', o.created_at) AS day,
       t.region,
       count(*)                        AS orders
FROM   {{ source('sales_pg', 'orders') }}   o
JOIN   lake.default.territories             t ON t.code = o.territory
GROUP  BY 1, 2

Files in object storage work too, including Excel:

SELECT * FROM read_xlsx('raw_files/finance/budget.xlsx')

Materializing

Write results into a catalog that permits writes — an Iceberg catalog is the usual destination:

# dbt_project.yml
models:
  my_project:
    +materialized: table
    +database: lake
    +schema: default

Remember Iceberg's virtual default: the schema is literally default.

Environment variables

Company-level variables are injected into every dbt run, so {{ env_var('WAREHOUSE_REGION') }} works without committing values. Set them in Settings → Environment variables. Reserved internal names are scrubbed from the run environment, so a variable cannot impersonate platform configuration.

Runs and logs

Each run records its status, duration and per-model timings, with full logs retained against the run. A failed model shows dbt's own error, not a wrapper.