The combination of Snowflake and dbt has become the standard modern data stack at hundreds of US and UK companies. Elegant in theory, powerful in practice — and genuinely overwhelming if you have been thrown into a production environment with no prior experience of either tool.
This guide explains why this stack trips up so many engineers, what the most common problems are and how to accelerate your path to competence.
Why Snowflake + dbt is Harder Than It Looks
Both tools have excellent documentation. Both have active communities. And yet data engineers consistently struggle when they encounter this stack for the first time in a production environment. The reasons are predictable:
- The conceptual model of dbt — models, refs, sources, tests, macros — is different from any ETL tool most engineers have used before
- Production dbt projects are often large and complex, with hundreds of models, custom macros and elaborate testing structures
- Snowflake's pricing model means that writing inefficient queries in production has immediate financial consequences that your manager will notice
- The interaction between dbt's compilation and Snowflake's query optimiser creates behaviour that is non-obvious until you understand both tools deeply
The Most Common dbt Mistakes in Production
1. Not understanding ref() vs source()
New dbt users often use raw table references instead of ref() and source(). This breaks lineage tracking, breaks environment targeting and makes the DAG invisible. Every model that depends on another model should use ref('model_name'). Raw source data should be declared in sources.yml and accessed via source('schema', 'table').
2. Materialisation mistakes
Defaulting everything to table materialisation causes full rebuilds on every run, which is slow and expensive in Snowflake. Most staging models should be view. Intermediate and mart models should be incremental where possible. table is appropriate for final aggregations that need to be fast to query.
3. Not writing dbt tests
Production dbt projects that lack tests cause silent data quality failures that only surface when a business user notices a wrong number in a dashboard. At minimum, every model should have not_null and unique tests on primary key columns, and accepted_values tests on categorical fields.
Common Snowflake Performance Problems
Warehouse sizing and auto-suspend
New engineers often leave warehouses running when not in use (auto-suspend should be set to 60 seconds for most workloads) or use warehouses that are too large for the query (causing unnecessary credit consumption) or too small (causing long queues).
Clustering keys
Large Snowflake tables without appropriate clustering keys result in full table scans. Choosing the right clustering key — typically the column most commonly used in WHERE or JOIN predicates — can reduce query time by orders of magnitude.
How to Get Up to Speed Faster
The fastest way to learn dbt and Snowflake in a production context is to work through actual problems in your actual codebase with someone who knows both tools deeply. Reading documentation builds conceptual understanding; daily sessions with an expert who can explain why your specific query is slow, why your specific model is failing and how to fix your specific data pipeline teaches you things that take months to learn alone.
Need job support right now?
Book a free 30-minute demo session. We assign a dedicated developer within 24 hours.