dbt strict analysis changes a Snowflake UNION timestamp type

A dbt project passes in baseline mode but fails when static_analysis: strict is enabled. In a fresh Snowflake issue, dbt_utils.union_relations() produces a timestamp type that conflicts with a downstream UNION ALL. The reporter's minimal reproduction uses a user whose TIMESTAMP_TYPE_MAPPING is TIMESTAMP_TZ; strict mode yields TIMESTAMP_NTZ for a unioned view, and Snowflake rejects the set operator. This is a migration risk where the stronger validation mode appears to change the resulting type.

Isolate the type boundary

Record dbt and adapter versions, Snowflake user settings, the macro version, and compiled SQL for the source view, union model, and downstream consumer. Query the actual column types in the warehouse after a baseline build. Then run the same minimal lineage under strict mode in a non-production schema. A changed compiled expression or cast is more useful evidence than the final error message alone.

Contain the upgrade by lineage

dbt's static-analysis guide says baseline is the default transition mode and strict adds type and function validation. It also documents that model-level modes cascade through lineage. Keep the affected branch on baseline while you investigate, rather than disabling analysis for the whole project. If you add an explicit cast, test that it matches the intended business timestamp semantics and timezone, then compare downstream values. A cast that merely quiets the compiler can shift a reporting boundary.

Make type checks part of release evidence

Add a small regression case with a timestamp mapped as in production, one union macro, and a downstream set operator. Assert both the warehouse column type and representative values across a timezone boundary. Track the upstream issue for a supported fix, then rerun the case before lifting the baseline exception. Ask for a compiled-SQL diff and data-type report in the migration review.

Adovo’s view

Strong analysis earns trust only when it preserves the meaning of the data. A green compile is not enough, and a red compile is not always a broken model. Treat type semantics as a production contract and make each migration exception small, visible, and reversible.