dbt seed bug: truncating leading zeros in csv columns

TL;DR

The warehouse inferred a numeric type for the column, so 00734 loads as 734. Force the column to text with +column_types in the seed config, then dbt seed --full-refresh to reload.

Error

dbt seed bug: truncating leading zeros in csv columns

Steps

1. Check the current column type in the warehouse for the seed table. Expected: it shows a numeric type like integer or numeric.
2. Add a column type override in dbt_project.yml under the seeds config:

seeds:
  +column_types:
    zip_code: varchar

Expected: the seed config pins the column to text.

1. Run dbt seed --select [SEED NAME] --full-refresh. Expected: the table is rebuilt with the text column.
2. Query the seed table and check the values. Expected: leading zeros are preserved.
3. Rerun downstream models and tests. Expected: everything downstream sees the correct values.

When to use

• Seed values like zip codes, product codes, or IDs lose leading zeros after dbt seed.
• The CSV itself has the zeros (verify by opening the raw file).

When not to use

• The CSV is missing the zeros (fix the source file, not the column type).
• A model (not the seed) strips the zeros (fix the model logic).

Tool compatibility

• dbt Core 1.0 and later, all adapters. The text type name varies (varchar, string, text).

Variant phrasings

Seed column loaded as float, values rounded

Same inference problem; pin the type explicitly.

CSV values look right in the file but wrong in the table

Type inference at load time is the culprit; the file is fine.

Why it happens

dbt infers seed column types from the CSV contents. All-digit values infer as numeric, and numeric storage drops leading zeros permanently at load time.

Edge cases

• Quoting values in the CSV does not reliably force text; the explicit column_types config is the robust fix.
• Changing the type requires --full-refresh; a plain dbt seed will not alter the existing table.
• Downstream joins on the column need matching types; changing seed type can break joins that relied on numeric.

Provenance

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