dbt seed: relation already exists, use --full-refresh
Fixes dbt seed failures on existing seed tables for analytics engineers and repair agents. Use when dbt seed refuses because the relation already exists. Not for CSV parsing errors or seed column issues.
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
dbt seed: relation already exists, use --full-refreshSteps
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.
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.
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.
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