## TL;DR

The snapshot block sets `target_database` to a database that does not exist in the warehouse. Either create that database or drop the override so the snapshot lands in the profile target's database. Then rerun `dbt snapshot`.

## Error

```text
"Snapshot target database does not exist" dbt snapshot error
```

## Steps

1. Open the snapshot file and find the `target_database` config in its config block. Expected: you see the database name dbt is trying to use.
2. Check whether that database exists in the warehouse (list databases in your warehouse UI or information schema). Expected: you confirm it is genuinely missing.
3. Either create the database in the warehouse, or remove the `target_database` line so the snapshot uses the default target database. Expected: the config now points at a database that exists.
4. Also verify `target_schema`; it must exist or be creatable by the dbt role. Expected: schema is present or the role can create it.
5. Run `dbt snapshot --select [SNAPSHOT NAME]`. Expected: the snapshot builds successfully.

## When to use

- `dbt snapshot` fails with "target database does not exist".
- You copied a snapshot config from another project with a different database name.

## When not to use

- The error is about a missing schema rather than a database.
- The snapshot fails on its `unique_key` or `strategy` (a config problem, not a missing database).

## Tool compatibility

- dbt Core 1.0 and later. Multi-database setups apply mostly to Snowflake, BigQuery, and Databricks.

## Variant phrasings

### Snapshot fails: database does not exist on BigQuery

On BigQuery the "database" is the project; the fix is the same: point at a real one.

### target_schema does not exist for snapshot

Sibling error: create the schema or let dbt create it with the right privileges.

## Why it happens

Snapshots allow overriding the target database and schema per snapshot. A stale or copied override points at a database nobody created in this warehouse, and the snapshot has nowhere to write.

## Edge cases

- The dbt role needs create-schema privileges if you expect dbt to make the schema itself.
- `target_database` on warehouses without a database concept is ignored; do not set it there.
- Hard-coding database names hurts portability across dev and prod; prefer leaving the default and overriding per target.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J05h501tLq-iIuS1dxgipw