How do incremental models work in dbt, and when do you use one instead of a full rebuild?

An incremental model builds the table once, then on later runs processes only new or changed rows and merges them in, using an is_incremental block to filter the source. Use one when a full rebuild is too slow or expensive, typically on large event tables. Keep a unique key so late updates merge rather than duplicate, and keep full refresh possible so you can rebuild after logic changes.

On the first run it builds the whole table. After that, the is_incremental block adds a filter so you only scan recent source rows, and dbt merges them into the existing table on a unique key. I only reach for it when a full rebuild has become genuinely painful, because incremental models carry state and state drifts. Two habits keep them honest. First, a lookback window rather than a strict greater than max timestamp, because sources update rows retroactively. We used three days on an orders model after finding that refunds landed up to 48 hours late and were being missed entirely. Second, a scheduled full refresh, weekly in our case, which both catches drift and proves the model can still be rebuilt at all. The failure I have seen is an incremental model with no unique key on an append only strategy, which quietly double counted every time a retry ran, and nobody noticed until a monthly number disagreed with finance.