The Incremental Model That Billed Like a Full RefreshWarehouse · medium · ~13 minThe user_events_dedup dbt model was converted to incremental three months ago — materialized='incremental', a proper is_incremental() filter on the source, unique_key='event_id' for dedup. The team celebrated and moved on.Finance did not. The model is now the single most expensive job on the platform: ~9,000 slot-hours per nightly run to land ~15M new rows into a 50B-row table. The engineer who owns it insists the config is correct — and the source scan *is* small.You pull the job stats before the cost review.Evidence

Job stats

Query plan excerpt

Model config

Checkpoints

The source scan is only 15M rows, yet the run scans 50B. Where does the full-table scan come from?

Roughly what percentage of the data scanned each run is actually new data being landed? (Use 15M new rows vs ~50B scanned.)

The duplicates analysis shows all duplicates arrive within 4 hours. What does this finding change?

Write the fix and its safety rails: the new materialization design, why the write side now prunes, and the two operational failure modes the new design introduces (the old full-refresh never had them).