Analytics engineers built dbt models materialized as tables, so every scheduled run rebuilds each large fact table from scratch and consumes heavy warehouse compute. New rows arrive daily, and older rows rarely change. Which change reduces the load on the warehouse?

dbt is a transformation tool that compiles models written as SELECT statements into SQL and runs that SQL in the warehouse, so its materialization choice directly affects database load. A table materialization drops and rebuilds the table on every run, reprocessing the entire history even when only a day's worth of rows is new. An incremental materialization builds the table once and then, on later runs, filters the source to new or changed rows, typically by comparing a timestamp or key against what already exists, and inserts or merges only those rows. For large fact tables with append-mostly data, that sharply reduces compute per run. Switching to views does not stop dbt generating SQL; dbt still creates the view definition, and the full transformation cost is then paid every time a dashboard or analyst queries the view. Running the full rebuild more often increases total work, because each run still reprocesses the entire history regardless of how recently the last one ran. Moving transformations into client-side scripts pulls large volumes of data out of the warehouse and loses dbt's version-controlled, testable models. Exam caveat: incremental models need a reliable way to identify new or changed rows, and late-arriving updates may require a periodic full refresh. Operational check: compare the compiled SQL and the warehouse's bytes processed for a full run and an incremental run, and confirm row counts match a full rebuild.