Features
dbt full refresh is a command-line flag that forces dbt to truncate and rebuild incremental models from scratch on the next run.
dbt full refresh is a CLI flag (--full-refresh) that tells dbt to drop existing tables for incremental models, then recreate and repopulate them as if they were brand-new. Use it when source data backfills, logic changes, or historical rows need recalculation.
Run a full refresh after changing business logic, adding columns that require historical recomputation, or receiving late-arriving data that invalidates prior increments. Avoid using it in every run because it is resource-intensive.
During execution, dbt checks model materialized = "incremental". If --full-refresh is present, dbt issues DROP TABLE or TRUNCATE followed by a fresh CREATE TABLE AS statement, bypassing the incremental filter logic.
Open your terminal in the dbt project root and run dbt run --full-refresh --select path/to/models. Append --threads to parallelize or --target prod to point at production.
# Rebuild all incremental models
dbt run --full-refresh
# Refresh only orders & payments models
dbt run --full-refresh --select orders payments
Schedule full refreshes during low-traffic windows to reduce load on the warehouse. Use dbt Cloud or orchestrators like Airflow to isolate refresh jobs. Always test refresh logic in staging before production.
Running full refresh in production hours can cause expensive warehouse scans. Forgetting to drop unused columns leads to silent errors. Overusing full refresh negates incremental model benefits.
Galaxy’s SQL editor lets you inspect incremental model SQL, validate --full-refresh queries, and share one-click snippets with teammates. The AI copilot explains query plans and flags cost drivers before you execute a refresh.
An e-commerce team backfilled five years of clickstream data. They ran dbt run --full-refresh --select fct_sessions overnight. Warehouse usage spiked as expected, but materializations aligned with the new historical dataset.
Incremental models, snapshot, seed, materialization, refresh schedule.
Full refresh protects data accuracy when incremental logic changes. Without it, historical rows remain stale, causing reporting discrepancies. Understanding refresh costs prevents runaway warehouse bills and keeps ELT pipelines efficient.
No. Models materialized as table or view are rebuilt as usual; only incremental models respect the --full-refresh flag.
Duration equals a full table rebuild: number of rows × query complexity × warehouse size. Monitor job logs for exact timings.
Yes. Terminate the dbt job or interrupt the orchestration task. Partial tables may remain; rerun without --full-refresh or drop tables manually.
Galaxy surfaces dbt-generated SQL, letting you review cost estimates and share refresh queries. The AI copilot suggests safer partition filters to avoid unnecessary full refreshes.
.avif){kind=logo}
