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

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.

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 columntypes entry to a wider type such as varchar(64) or text, or correct the CSV values. Keep the config in dbtproject.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/pstBN733rnU5TiY9BZLahN6w

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

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

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.