## TL;DR

The seed table column was created as varchar(16) (from config or inference) but a CSV value is longer, so Postgres rejects the insert. Either widen the seed column type in column_types, or trim the source values if 16 is the real business limit. Declaring the type explicitly stops inference from picking a width based on short early values.

```text
Database Error: value too long for type character varying(16) in dbt seed
```

## Use this when

- dbt seed on Postgres fails with value too long for type character varying(16)
- the length in the message matches a column_types setting or an inferred width for that seed
- the CSV contains at least one value longer than the stated width

## Not for this skill when

- the failing insert is from a model, not a seed, fix the model target column instead
- long values are data errors that must be rejected, keep the width and fix the source extract
- you can move the seed to a warehouse table managed outside dbt, then reference it as a source

## Steps

1. Find the longest value in the failing CSV column with a quick scan of the file, and read the seed column_types config for that column if one exists.
   Verify: you know the true maximum length and where the 16 came from.

2. Decide intent: if the column is a code that must stay 16, fix or reject the over-length source rows with the data owner. If the width was arbitrary, widen it.
   Verify: the intended column width is decided and recorded.

3. Apply the fix: set the seed column_types entry to a wider type such as varchar(64) or text, or correct the CSV values. Keep the config in dbt_project.yml or the seed YAML so fresh environments match.
   Verify: seed config or CSV now agrees with the chosen width.

4. Drop the partially loaded seed table if dbt left one, rerun dbt seed --select for that seed, and verify the column type and the longest loaded value.
   Verify: seed loads fully and the warehouse column width matches the config.

## Variant phrasings

### no column_types configured anywhere
Some adapters infer widths from the CSV. Inference can undershoot when long values appear late in the file; explicit types are the durable fix.

### error names a different length each run
Different seeds share a generic config block. Scope column_types per seed so one seed widening does not mask another seed problem.

Compatibility: dbt seed on Postgres and Redshift with explicit or inferred varchar widths; Snowflake and BigQuery use different length semantics. Applies to dbt-core 1.x seeds.

## Why it happens

Postgres enforces varchar(n) strictly on insert. dbt seed creates the table first using configured or inferred types, then streams CSV rows. A single over-length value aborts the load with this error, and because the table was created narrow, every retry fails identically until the type or the data changes.

## Edge cases / pitfalls

- Codes with meaningful leading zeros belong in varchar, but width still applies; padding is not trimming.
- A partial seed load can leave a half filled table that downstream models read; always rerun the seed to completion and check row counts.
- Widening to text everywhere avoids this class of error but loses a useful data quality signal for fixed-width codes.

## Provenance

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