dbt seed silently drops the last column of the csv

TL;DR

The last CSV column vanishes when the file uses inconsistent line endings, a trailing delimiter on the header only, or a final column name carrying a hidden carriage return, so dbt parses one fewer field. Clean the file to consistent LF endings, remove stray trailing delimiters, and reload the seed. Verify column count against the header before trusting the data.

dbt seed silently drops the last column of the csv

Use this when

• dbt seed succeeds but the loaded table lacks the CSV last column
• the header row ends with a comma, or the file was saved by Excel on Windows
• downstream models fail to find a column that is visibly in the CSV

Not for this skill when

• the column is excluded by an explicit seed config or a select in a model, remove that exclusion instead
• the file is not comma delimited (semicolons from locale Excel), fix the delimiter at export
• the column exists but is all null, that is a value parsing issue, not a dropped column

Steps

1. Inspect the raw file: check the header line ending bytes and whether the header has one more delimiter than the data rows (or the reverse). Tools like a hex view or reading with visible line endings reveal stray CR characters. Verify: you know the exact structural defect in the file.

2. Normalize the CSV: save with LF line endings, no trailing delimiter at line ends, UTF-8 encoding, and a final newline at end of file. Keep the change minimal and reviewable in a diff. Verify: the cleaned file has consistent delimiters per row and clean endings.

3. Drop the existing seed table and run dbt seed --select for that seed again (seeds do not always alter existing table shape in place). Verify: the seed reloads from the cleaned file.

4. Compare the loaded table columns against the CSV header one by one and count rows. Verify: every header column exists in the table with values populated, including the last one.

Variant phrasings

last column present but named with invisible suffix

A carriage return glued to the final header name creates a column that looks right in some tools and wrong in SQL. Renaming via a clean file fixes it; quoting the odd name only papers over it.

only breaks when edited by one teammate

Editor settings differ (CRLF defaults). Add an editorconfig or a CI check for seed files so the defect stops recurring.

Compatibility: dbt seed CSV loading on all adapters (agate based parsing). File hygiene: UTF-8, LF endings, consistent delimiters. Excel exports are the most common source.

Why it happens

CSV parsing is positional: the parser maps fields to header names by delimiter counts per line. A trailing delimiter or a CR character shifts the final field out of alignment or absorbs it into a malformed name, and because seeds tolerate a lot silently, dbt loads what parsed and reports success while the last real column never lands.

Edge cases / pitfalls

• A BOM at file start corrupts the first column the same way the CR corrupts the last; check both ends of the file.
• Quoted fields containing commas are legal CSV; do not fix counts by naive comma counting on such files.
• Add a schema test or column count check for critical seeds so a silent drop fails loudly next time.

Provenance

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

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

Thread query: dbt seed silently drops the last column of the csv

TL;DR: The last CSV column vanishes when the file uses inconsistent line endings, a trailing delimiter on the header only, or a final column name carrying a hidden carriage return, so dbt parses one fewer field. Clean the file to consistent LF endings, remove stray trailing delimiters, and reload the seed. Verify column count against the header before trusting the data.