Incremental model
A dbt materialization that, after the first full build, only processes and appends new or changed rows on each run — used to keep large fact tables affordable and fast to refresh.
On this page · 6 sections
- Category
- dbt
- Goes deeper in
- dbt for Analytics Engineers
By default dbt rebuilds a model from scratch every run. For a small model that's fine. For a billion-row events fact, rebuilding every run is slow and expensive. An incremental model fixes that: on the first run it builds the whole table, and on subsequent runs it only transforms rows that are new or changed, then inserts or merges them.
You define which rows are “new” with an `is_incremental()` filter — typically `where event_at > (select max(event_at) from {{ this }})`. You also set a `unique_key` so dbt can merge updates rather than create duplicates.
Incremental models trade simplicity for performance, and they introduce edge cases (late-arriving data, backfills, schema changes). Use them when a full refresh cannot meet the model's runtime or cost constraints, not by default.
Incremental models are how analytics teams keep warehouse bills and run times under control as data volume grows. The difference between a 2-minute and a 2-hour pipeline run is often a few well-built incremental models.
They're also a common source of subtle bugs, so understanding them well is what separates a model that's merely fast from one that's fast AND correct.
- Adding incremental logic prematurely to small models, paying complexity cost for no benefit.
- Omitting a `unique_key`, so re-processing a window inserts duplicates instead of merging.
- Not handling late-arriving data, so rows that show up after the watermark are silently missed.
- When should I make a dbt model incremental?
- When the table is large enough that a full rebuild each run is too slow or expensive — typically big event/fact tables. Keep smaller models on full refresh for simplicity.