DVT SNAPSHOT
dvt snapshot executes the snapshots defined in your project, recording how selected rows change over time — type-2 history, captured run by run. If you use dbt snapshots today, this command works exactly as you know it: same files, same strategies, same flags, same meta columns.
THE MINIMAL INVOCATION
No flags needed. Every snapshot in the project runs against your default target:
$ dvt snapshot 10:41:07 Found 12 models, 2 snapshots, 9 data tests, 4 sources 10:41:07 Concurrency: 4 threads (target='dev') 10:41:07 10:41:07 1 of 2 START snapshot snapshots.customers_snapshot ............... [RUN] 10:41:09 1 of 2 OK snapshotted snapshots.customers_snapshot ............... [SUCCESS 42 in 1.32s] 10:41:09 2 of 2 START snapshot snapshots.products_snapshot ................ [RUN] 10:41:10 2 of 2 OK snapshotted snapshots.products_snapshot ................ [SUCCESS 7 in 0.98s] 10:41:10 10:41:10 Finished running 2 snapshots in 0 hours 0 minutes and 2.41 seconds (2.41s). 10:41:10 10:41:10 Completed successfully 10:41:10 10:41:10 Done. PASS=2 WARN=0 ERROR=0 SKIP=0 TOTAL=2
The first run creates each snapshot table and copies every row in; every run after that records only what changed. This page is about the command — for the snapshot files themselves (strategies, the four meta columns, the config reference, and where the history physically lives), see Snapshots.
SELECTING WHICH SNAPSHOTS RUN
Selection is dbt's node-selection syntax, unchanged — the same expressions dvt run takes:
dvt snapshot --select customers_snapshot # one snapshot by name dvt snapshot --select tag:nightly # every snapshot tagged nightly dvt snapshot --exclude products_snapshot # everything but this one dvt ls --resource-type snapshot # list them without running anything
Snapshots also run as part of dvt build — seeds, models, snapshots and tests in DAG order, so a snapshot that reads a model runs after that model builds.
Like every graph verb, dvt snapshot starts from a passing parse and a signed-in machine — a broken project refuses with the parse error, before anything runs. Help is never gated: dvt snapshot --help answers on any machine, in any project state.
--EMPTY — THE SCHEMA-ONLY DRY RUN
The command's one flag of its own. --emptyruns every selected snapshot against zero rows: the table is built and validated, the strategy and config are exercised, and nothing is recorded. It's the safe way to prove a new snapshot compiles and lands before you let it start accumulating history:
dvt snapshot --select orders_snapshot --empty
WHERE THE WORK LANDS — AND WHAT DVT REMEMBERS
Snapshots execute on your default target, in its native dialect, through the official adapter — a pure pass-through. Only models can be federated in DVT; a target=pin in a snapshot's config has no effect, and DVT says so out loud rather than half-honoring it. Data on an engine your warehouse can't reach? Land it first with a federated model, then snapshot the landed copy — the Snapshots page walks through that pattern.
What DVT adds around the run: every snapshot table that lands is recorded in the project's materialization ledger — the same record dvt retract reads back when you want the project's footprint gone.
IN PLAIN DBT
A snapshot table is created and then forgotten by the tool — nothing remembers it landed, so cleanup means finding it by hand in the warehouse. DVT's ledger records the landing as it happens, and dvt retract can tear it down with everything else, in reverse dependency order.
ON A TARGET FLIP
When you flip the default target, snapshots are transpiled to the new engine's dialect exactly like models — their SQL body translated, their {% snapshot %} Jinja preserved byte-for-byte, with their own line in the flip report. See Flipping the default target.
REFERENCE — THE FLAGS
dvt snapshot --helpanswers in DVT's own voice — the command's own flag first, then the engine-wide options every parity verb shares:
$ dvt snapshot --help
usage: dvt snapshot [OPTIONS]
DVT snapshot — Capture slowly-changing dimensions
Executes the snapshots defined in your project, recording how selected
rows change over time.
EXAMPLES:
dvt snapshot
dvt snapshot --select customers_snapshot
OPTIONS FOR SNAPSHOT:
--empty / --no-empty
Run against zero rows — a schema-only dry run.
...| FLAG | WHAT IT DOES |
|---|---|
| --empty / --no-empty | Run against zero rows — a schema-only dry run that builds and validates the snapshot table without recording anything. |
| -s, -m, --select, --models, --model | Specify the nodes to include — dbt node selection: names, tag:, path:, graph operators. |
| --exclude | Specify the nodes to exclude (same syntax). |
| --selector | A named selector from selectors.yml. |
| --resource-types / --exclude-resource-types | Restrict the run to these resource types, or leave them out. |
| --project-dir | Which directory to look in for dbt_project.yml. Default is the current working directory and its parents. |
| --profiles-dir | Which directory to look in for profiles.yml. If not set, the project directory is tried first, then ~/.dbt/ |
| --profile | Which existing profile to load. Overrides the setting in dbt_project.yml. |
| -t, --target | Which target to load for the given profile — run the snapshots against another profile output for this invocation. |
| --vars | Supply variables to the project as a YAML string, overriding dbt_project.yml. |
| --threads | Number of threads to use while executing. Overrides the setting in profiles.yml. |
| -x, --fail-fast / --no-fail-fast | Stop execution on the first failure. |
| --state | Use this state directory for both state comparison and deferral. |
| --defer / --no-defer | Resolve unselected nodes by deferring to the manifest within the --state directory. |
The rest of the engine-wide block — logging, parsing, warnings-as-errors, artifacts — is identical across every parity verb, and dvt snapshot --helpprints all of it, grouped by what you're trying to do. Every spelling and every --no-counterpart is the engine's own, so a flag you read there means exactly what it always meant.