The dbt Project Structure

Every dbt project is anchored by dbt_project.yml, a required YAML file at the project root that declares the project's name, the dbt version it targets, and default configuration — such as materialization strategy or schema — applied to models in specific folders. dbt reads this file first on every invocation to understand the project's shape, and it is what turns an ordinary directory of SQL files into something dbt recognizes as a project it can compile and run.

A scaffolded dbt project contains several purpose-built folders: models/ holds the SQL SELECT statements that become tables or views; seeds/ holds small static CSV files dbt can load directly, useful for lookup tables like country codes; snapshots/ holds logic for capturing slowly changing dimensions over time; macros/ holds reusable Jinja functions callable from any model; tests/ holds custom singular data tests written as SQL; and analyses/ holds ad hoc SQL that compiles but is never run as part of dbt run.

Within models/, the widely adopted convention splits SQL into three layers: staging models (prefixed stg_) do light cleanup of a single raw source table — renaming columns, casting types — with a one-to-one relationship to that source; intermediate models combine or reshape multiple staging models for a specific purpose; and mart models (in a marts/ subfolder, often further split into marts/finance/ or marts/marketing/) produce the final, business-facing tables that dashboards and analysts query directly. This staging-intermediate-marts layering keeps raw cleanup logic separate from business logic, so a single source-column rename doesn't need to be repeated across a dozen downstream models.