Data dbt Snapshots and Slowly Changing Dimensions

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

dbt snapshots tell agents whether historical row changes are expected, missing, or broken because the snapshot strategy no longer matches the source table.

## Core Explanation

Mutable source tables can overwrite the past. dbt snapshots preserve a history of those changes, which is useful for audits and slowly changing dimensions but creates its own failure modes. A bad unique key, missing `updated_at`, schema drift, or hard delete policy can make history incomplete even when the latest source row looks correct.

Agents should inspect snapshot name, unique key, strategy, updated_at or check columns, target schema, validity columns, hard delete settings, source freshness, dbt run artifacts, and downstream model assumptions before backfilling or rebuilding snapshot tables.

## Source-Mapped Facts

- dbt documentation says snapshots record changes to a mutable table over time. ([source](https://docs.getdbt.com/docs/build/snapshots))
- dbt documentation says snapshots implement type-2 Slowly Changing Dimensions over mutable source tables. ([source](https://docs.getdbt.com/docs/build/snapshots))
- dbt strategy configuration documentation says snapshot strategy is required and can use timestamp or check examples. ([source](https://docs.getdbt.com/reference/resource-configs/strategy))

## Further Reading

- [dbt Snapshots](https://docs.getdbt.com/docs/build/snapshots)
- [dbt Snapshot Strategy](https://docs.getdbt.com/reference/resource-configs/strategy)