## TL;DR

dbt seed will not overwrite an existing table by default. If the CSV changed and you want it replaced, run dbt seed --full-refresh. If the table was created by something else, check it is really your seed before dropping it.

## Error

```text
dbt seed: relation already exists, use --full-refresh
```

## Steps

1. Confirm the existing table is actually your seed: check its row count and a few rows against the CSV.
   Expected: You know whether the table matches the CSV or is something else squatting on the name.

2. If it matches and you want the new CSV loaded, run dbt seed --select the_seed --full-refresh.
   Expected: The seed table is dropped and recreated from the CSV.

3. If the table is NOT your seed, rename your seed or the squatter; do not full-refresh over someone else's table.
   Expected: Name collision resolved without data loss.

4. Re-run dbt seed normally to confirm idempotence.
   Expected: Seed succeeds without the flag when nothing changed.

## When to use

- dbt seed fails with relation already exists
- the CSV changed and you need the table reloaded
- a previous seed run was interrupted mid-create

## When not to use

- CSV parsing errors (that is the file content, not the existing table)
- you want incremental seed loads (seeds are full loads by design)
- the seed table has the wrong schema (check the CSV header and types)

## Tool compatibility

- dbt seed; --full-refresh drops and recreates seed tables
- dbt Cloud: seed jobs accept the same flag
- seeds live in the seeds/ directory as CSVs

## Variant phrasings

### relation already exists in CI only
CI seeds into a schema that a previous run populated. Either full-refresh the seed step or have CI use a fresh schema per run.

### seed exists but with old data, no error
dbt seed without --full-refresh skips existing tables silently. That is by design; the flag is how you force a reload.

## Why it happens

Seeds are meant to be stable reference data, so dbt treats an existing seed table as already loaded and refuses to clobber it. The error is dbt asking you to confirm the overwrite explicitly with --full-refresh.

## Edge cases

- --full-refresh on a seed drops the table; any grants on it need reapplying if your warehouse does not preserve them.
- Large CSVs as seeds are slow; if the file keeps changing, consider an external table or a proper ingestion instead.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9R99qdRE17eEnGoVTLG6Kg