Catastrophic Pattern Detector

Flag bill-blowup patterns before they merge

Enter the changed dbt model name. dbtGuard analyzes the diff, resolves downstream models, and flags the patterns most likely to spike your BigQuery bill.

Uses the sample jaffle_shop diff (fixtures/sample_diff.sql). In production, the GitHub Action passes your PR's before/after SQL.

🚨

Critical risk — merge should be blocked

4 patterns detected in this diff

CRITICAL
Config change — base branch vs PR branch
Before (base branch)
materialized incremental
incremental_strategy merge
unique_key order_id
partition_by yes
incremental filter yes
After (PR branch)
materialized table
incremental_strategy —
unique_key —
partition_by yes
incremental filter no
Detected patterns — 4 found
critical Incremental → full-refresh switch INCREMENTAL_TO_FULL_REFRESH
What this means

Model materialization changed from incremental to table. Every pipeline run will now scan the entire table instead of only recent rows. This is the most common cause of 10–100× BigQuery bill spikes.

Recommendation

If you need to add columns, use materialized='incremental' with a schema migration. Only switch to table if a one-time full rebuild is intentional, then switch back.

critical Partition filter removed PARTITION_FILTER_DROPPED
What this means

The {% if is_incremental() %} WHERE clause that restricted scans to recent partitions was present in the base branch but removed in this PR. BigQuery will now scan all partitions on every run, which can multiply cost by 10–100×.

Recommendation

Restore the incremental WHERE guard with a date lookback window. If you need to backfill historical data, run dbt run --full-refresh once, then restore the filter.

high New join on `my-bq-project.raw.discounts` UNFILTERED_JOIN_INTRODUCED
What this means

A new JOIN on my-bq-project.raw.discounts was added in this PR. If this is a large table without a filter on the ON or WHERE clause, BigQuery will scan the full table on every run even if only a few rows match.

Recommendation

Add a partition filter or selective WHERE clause on my-bq-project.raw.discounts. If it is a small lookup table (≤1 GB), this pattern is low risk.

high Large-table downstream fan-out (4 models ≥1 GB) LARGE_TABLE_FAN_OUT
What this means

4 downstream model(s) — rpt_customer_ltv, rpt_daily_revenue, rpt_cohort_analysis, fct_orders — collectively hold 30.0 GB and will inherit the upstream change's full-scan cost on every pipeline run.

Affected downstream models
rpt_customer_ltv 7.0 GB
rpt_daily_revenue 12.0 GB
rpt_cohort_analysis 3.0 GB
fct_orders 8.0 GB
Recommendation

Check that each downstream incremental model has its own lookback filter. If any are table materializations they will re-scan from scratch every run.