dbt on Snowflake: a pragmatic blueprint for analytics engineering

dbt and Snowflake have become the default pairing for modern analytics engineering. The tooling is easy to start with — which is exactly why so many projects become hard to maintain after the first year. This is the blueprint I use to keep them healthy.

Layer the project deliberately

• Staging — one model per source table: renaming, typing, light cleaning. No joins.
• Intermediate — reusable business logic, joins and deduplication.
• Marts — dimensional models and wide tables designed for consumption by BI and AI.

Enforce the direction of dependencies: marts can reference intermediate and staging models, never the other way round. Tools such as dbt-project-evaluator can check this automatically.

Test what the business cares about

Generic tests (unique, not_null, relationships) are table stakes. The tests that prevent incidents encode business rules: revenue is never negative, every order has a customer, daily row counts stay within an expected range. Model contracts on mart models protect downstream consumers from silent schema changes.

Make Snowflake costs visible

• Use separate, right-sized warehouses for dbt runs, BI and ad-hoc work.
• Prefer incremental models for large fact tables and review them regularly.
• Set query_tag per model so compute cost can be attributed in ACCOUNT_USAGE.

models:
  my_project:
    +query_tag: dbt
    marts:
      +materialized: table
      +snowflake_warehouse: TRANSFORM_M

Ship it like software

Every pull request should build and test only the modified models and their children (dbt build --select state:modified+) against a zero-copy clone of production. It is fast, cheap on Snowflake, and catches breaking changes before they reach a dashboard.

A dbt project built this way is also the best foundation for AI: documented models, defined metrics and tested data are exactly what LLM-powered analytics need to give correct answers.