Seeds

Analogy categoryAnalogies

What Seeds Are and When to Use Them

A seed is a CSV file placed in your project's seeds/ directory that dbt loads into your warehouse as a table via the dbt seed command. Seeds are meant for small, static, rarely-changing datasets that live naturally in your codebase rather than in a production source system — classic examples are a country-code-to-region mapping, a list of holiday dates for a fiscal calendar, or a manual list of employee-to-department assignments that a business team maintains by hand. Because seeds are version-controlled alongside your models, changes to them go through the same code review and git history as any other transformation logic, which is exactly the point: they're reference data that should be reviewable, not a database table someone edits directly and silently.

🏏

Cricket analogy: This is like a scorer keeping a small reference sheet mapping each ground's abbreviation, like 'MCG' or 'Eden Gardens', to its full name and capacity — a static list maintained by hand, not something pulled from a live match-data feed.

Loading and Referencing Seeds

Running dbt seed reads every CSV in the seeds/ directory (or a subset via --select) and loads it as a table in your warehouse, inferring column types from the data unless you override them in a seed's YAML config with a column_types map. Once loaded, a seed is referenced from any model exactly like a regular model — with ref('seed_file_name') — which means it participates fully in the DAG, gets documented in dbt docs, and can have schema tests like unique or not_null attached to it just like any other model.

🏏

Cricket analogy: This is like a groundskeeper walking every ground on the circuit and loading its capacity into the official records system in one batch pass, and afterward, any match report just looks up that ground the same way it looks up any other stored fact.

sql

-- seeds/country_region_map.csv
-- country_code,region
-- US,North America
-- IN,Asia
-- DE,Europe

-- models/marts/dim_customers.sql
select
    c.customer_id,
    c.country_code,
    r.region
from {{ ref('stg_app__customers') }} c
left join {{ ref('country_region_map') }} r
    on c.country_code = r.country_code

Configure seeds in dbt_project.yml under a seeds: key, e.g. to set column_types or a custom schema for a specific seed file. Seeds also support schema tests in a seeds/schema.yml file exactly like models do — it's common to add unique and not_null tests on a mapping seed's key column.

Seeds are not meant for large or frequently-changing datasets — dbt seed loads the entire CSV on every invocation, and very large files (tens of thousands of rows or more) will slow down your CI pipeline noticeably. If data changes often or is large, it belongs in a real source system loaded via an EL tool, not a seed.

Seeds are CSV files in seeds/ loaded into the warehouse as tables via dbt seed.
They're for small, static, rarely-changing reference data that should be version-controlled and code-reviewed.
Seeds are referenced from models with ref('seed_file_name'), just like any other model.
Column types can be overridden via a column_types config if type inference guesses wrong.
Seeds support schema tests (unique, not_null) exactly like regular models.
Seeds are not suited for large or frequently-changing data — that belongs in a real source loaded via an EL tool.
Seeds fully participate in the DAG and appear in dbt docs like any other node.