Configuring a snapshot to track slowly changing data

As of dbt v1.9+, snapshots can be defined in YAML files under a snapshots: key, similar to how sources and models are configured, rather than only using the legacy Jinja/SQL snapshot block syntax. YAML snapshots use select to define the query (often referencing a source or model) and require a config block for strategy, unique_key, and check/timestamp columns. This objective tests your ability to correctly structure and configure a YAML-based snapshot definition.

1 · Learn the must-know

• 1YAML snapshots are defined in .yml files under a snapshots: top-level key, with each snapshot having a name and a relation or select pointing to the source table.
• 2Required config fields are strategy (timestamp or check), unique_key, and either updated_at (for timestamp strategy) or check_cols (for check strategy).
• 3The target_schema config is deprecated in favor of letting snapshots follow the same custom schema logic as models; use schema config or generate_schema_name macro instead when applicable.
• 4You can still use the legacy .sql snapshot block syntax with {% snapshot %}...{% endsnapshot %}, but YAML snapshots are the current recommended approach and both cannot define the same snapshot simultaneously.
• 5Snapshots configured in YAML support the same config options as SQL-defined snapshots, including invalidate_hard_deletes, strategy, and unique_key, and can also be configured via dbt_project.yml under the snapshots: key for project-wide defaults.
• 6A common gotcha: the select (or relation) in a YAML snapshot must resolve to a single table/query representing the mutable source data being tracked—snapshots still cannot be built on ephemeral models.

2 · Check your understanding