SOURCES.YML

THE CONNECTION: PROPERTY

The connection:property is DVT's key extension to dbt's sources.yml. Declared under the source's meta:block (dbt's schema only allows custom keys there), it links a source to a specific output in profiles.yml, telling DVT which database this data lives on.

EXAMPLE

# models/staging/sources.yml
version: 2

sources:
  # ─── External Sources (need connection:) ───

  - name: crm
    description: "CRM data from MySQL operational database"
    meta:
      connection: mysql_ops              # ← REQUIRED: points to profiles.yml
    tables:
      - name: customers
        description: "Customer master data"
      - name: orders
        description: "Sales orders"
      - name: products

  - name: warehouse
    description: "ERP data from Snowflake"
    meta:
      connection: sf_warehouse           # ← REQUIRED: points to profiles.yml
    database: PROD_DB
    schema: RAW
    tables:
      - name: invoices
      - name: shipments
      - name: vendors

  - name: data_lake
    description: "Raw files from S3"
    meta:
      connection: data_lake              # ← works with bucket storages too
    tables:
      - name: web_events
      - name: app_logs

  # ─── Default Target Sources ───

  - name: analytics
    description: "Tables on the default PostgreSQL target"
    schema: public
    meta:
      connection: pg_dev                 # ← recommended even here: dbt ignores
    tables:                              #   it, and a future target switch is free
      - name: seed_categories
      - name: dim_dates
      - name: historical_metrics

HOW DVT USES SOURCES

The execution path is chosen by the model's materialized config — not by the sources. What meta.connection controls is where a federated model extracts each source from:

A standard model should only read sources that live on the default target. The moment a model needs data from another engine, declare it federated yourself — DVT will coerce it for you rather than fail, but an explicit materialization states your intent and silences the warning. See f_table on the federated materializations page.

COMMON PATTERNS

Multi-source extraction model:

-- models/marts/cross_engine_report.sql
-- crm is on MySQL, warehouse is on Snowflake
-- Both get extracted → DuckDB joins them → result loads to default target

{{ config(materialized='f_table') }}

SELECT
    c.customer_name,
    i.invoice_date,
    i.total_amount
FROM {{ source('crm', 'customers') }} c          -- MySQL (extracted)
JOIN {{ source('warehouse', 'invoices') }} i      -- Snowflake (extracted)
    ON c.customer_id = i.customer_id

Default-target pushdown model:

-- models/staging/stg_categories.sql
-- analytics source has no connection: → pushdown on default target
-- SQL dialect: PostgreSQL (native)

{{ config(materialized='view') }}

SELECT id, name, parent_id
FROM {{ source('analytics', 'seed_categories') }}

Bucket storage source:

-- models/staging/stg_web_events.sql
-- data_lake source points to S3 → extracted via Sling

{{ config(materialized='f_table') }}

SELECT event_id, user_id, event_type, event_timestamp
FROM {{ source('data_lake', 'web_events') }}

SOURCE PROPERTIES REFERENCE

COMMON MISTAKES

sources:
  - name: analytics
    connection: pg_dev           # ← top level: dbt REJECTS this
    tables:
      - name: dim_dates

sources:
  - name: analytics
    meta:
      connection: pg_dev         # ← under meta: dbt allows, DVT reads
    tables:
      - name: dim_dates

sources:
  - name: crm
    # Missing connection!
    tables:
      - name: customers        # lives on MySQL

sources:
  - name: crm
    meta:
      connection: mysql_ops      # external source
    tables:
      - name: customers