dbt BigQuery error: timestamp partition field missing

Not specified by the original author.

TL;DR

BigQuery partitioning is physical: the partition_by field named in the dbt config must be a timestamp or date column that the model SQL actually returns, with exactly that name and a partitionable type. The error means the config and the SQL disagree, often after a column rename, a select star that dropped it, or partitioning on an integer or string column. Align the config field, the SQL output column, and its type, then rebuild the table, because partitioning cannot be changed in place.

dbt BigQuery error: timestamp partition field missing

Use this when

• A dbt run on BigQuery fails saying the timestamp partition field is missing or invalid.
• The model was recently changed: a column renamed, a macro swapped, or partitioning newly added.
• The same model works as a view but fails when materialized as a partitioned table or incremental model.

Not for this skill when

• The error is about a partition filter requirement on a query against the table. That is a query setting, not a model build failure.
• The destination is not BigQuery. Other warehouses partition differently.

Steps

1. Read the compiled SQL for the model and check the final select list for the exact column named in partition_by, including case and any alias. Note whether it is present. Verify: presence of the partition column is settled from compiled SQL, not the source file alone
2. Check the column type in the compiled model and in any upstream cast: it must be date, timestamp, or datetime as your partition config declares. Note a string typed lookalike if you find one. Verify: the partition column has a partitionable type
3. Compare the partitionby block in the model config with the SQL: field, datatype, and granularity must agree, and an incremental model needs the same field on every run. Note any drift between them. Verify: config and SQL describe the same partitioning
4. Fix the side that is wrong: rename the output column back, add the missing cast, or correct the config field. Note the change and why that side owned the truth. Verify: one consistent partition definition remains
5. Rebuild the table with a full refresh, because an existing table keeps its original partitioning, then run the model tests. Note the table info in BigQuery shows the expected partitioning. Verify: the physical table is partitioned as configured

Variant phrasings

dbt bigquery partition_by field not found in model

The config-focused phrasing.

bigquery cannot partition on missing timestamp column dbt

The warehouse side wording.

Compatibility: dbt-bigquery adapter, table and incremental materializations. Partitioning fields, granularity, and the requirement to rebuild on a partitioning change are BigQuery platform rules.

Why it happens

dbt translates partition_by into the DDL that creates the BigQuery table, and BigQuery validates that DDL against the query result schema. If the named column is absent or the wrong type, table creation has no partition column to use and the job fails before any data lands. The disagreement usually creeps in through indirection: a macro that renames columns, an upstream model that changed a timestamp into a string for display, or a config copied from another model whose date column has a different name.

Edge cases / pitfalls

• Renaming a partition column on an incremental model strands history. Plan a full refresh and expect downstream partition filters to need the new name.
• A date column cannot serve a config that declares timestamp granularity semantics the adapter does not map. Match data_type in the config to the real column.
• Partitioning on a nullable timestamp puts nulls in a special partition. If the column is often null, the partitioning design itself needs a rethink.
• Select star from an upstream model makes this error return whenever upstream changes. List columns explicitly in partitioned models.

Provenance

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

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

Thread query: dbt BigQuery error: timestamp partition field missing

TL;DR: BigQuery partitioning is physical: the partition_by field named in the dbt config must be a timestamp or date column that the model SQL actually returns, with exactly that name and a partitionable type. The error means the config and the SQL disagree, often after a column rename, a select star that dropped it, or partitioning on an integer or string column. Align the config field, the SQL output column, and its type, then rebuild the table, because partitioning cannot be changed in place.

Not specified by the original author.

TL;DR

Upgrade to a release carrying the fix. If a dbt Fusion --sample run fails on BigQuery with a timestamp coercion error, look at the compiled filter: 9-digit fractional seconds are the fingerprint.

Steps

1. If a dbt Fusion --sample run fails on BigQuery with a timestamp coercion error, look at the compiled filter: 9-digit fractional seconds are the fingerprint. Upgrade to a release carrying the fix. Agents generating dbt sample windows should never hand-format timestamps at nanosecond precision for BigQuery; cap at 6 fractional digits to match what the warehouse accepts.

When to use

You are seeing this: '2026-06-05T03:50:56.538507786+00:00'. Use this skill when you run into "dbt Fusion --sample emitted nanosecond timestamps BigQuery rejects".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: GitHub issue dbt-labs/dbt#15242 (closed): on dbt Fusion with BigQuery, the --sample flag injected an event-time filter whose timestamp literals carried 9 fractional-second digits (nanosecond precision), e.g. '2026-06-05T03:50:56.538507786+00:00'. BigQuery TIMESTAMP and DATETIME support only 6 digits, so the implicit string-to-timestamp coercion failed and the run errored. Manually trimming the literal to 6 digits made the query valid. Fun root cause from the fix thread: the bug never showed for timestamps whose last three digits were 000, because Rust's AutoSi formatting trimmed them to microseconds. Fix merged.

Verified resolution: If a dbt Fusion --sample run fails on BigQuery with a timestamp coercion error, look at the compiled filter: 9-digit fractional seconds are the fingerprint. Upgrade to a release carrying the fix. Agents generating dbt sample windows should never hand-format timestamps at nanosecond precision for BigQuery; cap at 6 fractional digits to match what the warehouse accepts.

Source URL: https://github.com/dbt-labs/dbt/issues/15242

Not specified by the original author.

TL;DR

The query references project.dataset.table and BigQuery cannot see it. Usually the table has not been built yet in this target, or the dataset or project in your profile is wrong. Check the fully qualified name in the compiled SQL, verify the dataset exists, and build the missing upstream model first.

Error

BigQuery Not found: Table error in dbt run

Steps

1. Open target/compiled for the failing model and copy the fully qualified table name from the error. Expected: You have project.dataset.table exactly as BigQuery saw it.

2. In the BigQuery console, check the dataset exists in that project and region. Dataset region must match the job region. Expected: You confirm the dataset exists, or you find the project or region is wrong.

3. Check whether the table is a dbt model that has not been built in this target yet: run dbt ls --select +the_model to see its upstream chain. Expected: You find the unbuilt upstream model.

4. Build upstream first: dbt build --select +thefailingmodel, or fix the profile's dataset/project if those were wrong. Expected: Upstream tables exist, the failing model builds clean.

When to use

• BigQuery Not found: Table during dbt run
• a model refs another model that was never built in this target
• profile points at the wrong project or dataset

When not to use

• access denied on the table (that is IAM, not not-found)
• dataset location mismatch errors (region error, different message)
• the table exists but the query is wrong (that is SQL logic)

Tool compatibility

• dbt-bigquery adapter; profile dataset and project settings
• BigQuery console to verify datasets and regions
• dbt build --select +model builds upstream chain first

Variant phrasings

Not found: Table on a source

The source table itself is missing or the source definition's dataset is wrong. Check sources.yml against the real dataset.

Not found only in a new target

The target uses a different dataset that was never populated. Build the full DAG into it once, or point the target at the shared dataset.

Why it happens

BigQuery resolves the full three-part name at query time. dbt generates that name from your profile (project, dataset) plus the model config. Any mismatch, or any upstream model not yet materialized in that dataset, reads as not found.

Edge cases

• BigQuery dataset regions matter: a dataset in EU queried from a US job fails differently, but a wrong-region dataset name can also surface as not found.
• Table expiration can delete tables out from under you; check the dataset's default table expiration if tables vanish.

Provenance

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

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

Thread query: BigQuery Not found: Table error in dbt run

TL;DR: The query references project.dataset.table and BigQuery cannot see it. Usually the table has not been built yet in this target, or the dataset or project in your profile is wrong. Check the fully qualified name in the compiled SQL, verify the dataset exists, and build the missing upstream model first.