{"dataset":{"id":"00000000-0000-0000-0000-000000000058","slug":"dbt-best-practices","name":"dbt best practices","description":"Source-linked guidance on dbt fundamentals: project structure, models and materializations, tests and documentation, sources and refs, and deployment. Scoped to current dbt docs.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Deploy jobs","sourceUrl":"https://docs.getdbt.com/docs/deploy/deploy-jobs","text":"Deploy jobs build production data assets by running dbt commands against a project in your cloud data platform, triggered by schedule or events. Each run gets a run history entry with trigger type, commit SHA, environment name, and run timing; dbt v2 runs also offer downloadable OpenTelemetry logs per step. Prerequisites: a dbt account with a Developer seat license, a project connected to a data platform, access permission to view, create, modify, or run jobs, and a deployment environment. Commands default to dbt build, and chained built-in commands mean one failed run step fails the entire job with an Error status. dbt uses UTC for all jobs and does not adjust for local timezone or daylight saving time. Scope: dbt. Reviewed October 4, 2026.","id":"dbt-best-practices:Deploy jobs","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Add sources to your DAG","sourceUrl":"https://docs.getdbt.com/docs/build/sources","text":"Define sources in .yml files nested under a sources: key to name and describe the data loaded into your warehouse by Extract and Load tools. Selecting from source tables in models with the {{ source() }} function helps define lineage, test assumptions about source data, and calculate freshness; dbt compiles the reference to the full table name and creates a dependency between the model and the source table. By default, schema will be the same as name; add schema only if you want a source name that differs from the existing schema. You can also add data tests to sources and descriptions that render as part of your documentation site, familiar concepts if you have already tested and documented models. Scope: dbt. Reviewed October 4, 2026.","id":"dbt-best-practices:Add sources to your DAG","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Add data tests to your DAG","sourceUrl":"https://docs.getdbt.com/docs/build/data-tests","text":"Data tests are assertions about models and other resources such as sources, seeds, and snapshots; out of the box you can test for non-null values, unique values, values with a corresponding value in another model, and values from a specified list. Singular data tests are one-off assertions saved as .sql files, typically in the tests directory defined by the test-paths config. Generic data tests are parameterized queries defined in a test block and referenced from .yml files. Both return failing records; zero failing rows means a pass. You can use Jinja, including ref and source, in test definitions. Unit test YAML definitions must live under model-paths, and the tests: key remains an alias for data_tests:. Scope: dbt. Reviewed October 4, 2026.","id":"dbt-best-practices:Add data tests to your DAG","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Materializations","sourceUrl":"https://docs.getdbt.com/docs/build/materializations","text":"Materializations are strategies for persisting dbt models in a warehouse, with five built-in types: table, view, incremental, ephemeral, and materialized view; custom materializations extend dbt for specific needs. By default, models are materialized as views, rebuilt via a create view as statement on each run so no additional data is stored. Set a different materialization with the materialized configuration parameter in dbt_project.yml, applied per model directory as in the example materializing all models in models/events as tables; directly in model SQL files with {{ config() }}, useful alongside performance optimization configs such as Redshift sort and dist settings; or in the model's properties.yml file. Scope: dbt. Reviewed October 4, 2026.","id":"dbt-best-practices:Materializations","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"How we structure our dbt projects","sourceUrl":"https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview","text":"Structure models in the models directory across three primary layers that build on each other: Staging, Intermediate, and Marts. Staging creates atoms, the initial modular building blocks, from source data. Intermediate stacks layers of logic with clear, specific purposes to prepare staging models to join into the entities you want. Marts bring the modular pieces together into a wide, rich vision of the entities your organization cares about. In the example project, seeds in seeds/jaffle-data/ can populate the raw schema for local development when load_source_data is enabled, and YAML files sit alongside SQL models in the marts and staging folders. The project also uses data-tests, macros, and analyses folders plus packages.yml. Scope: dbt. Reviewed October 4, 2026.","id":"dbt-best-practices:How we structure our dbt projects","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}