Snowflake development operations¶
Warehouse cost controls¶
Use a dedicated, small development warehouse with auto-resume and a short auto-suspend interval. The setup example uses an X-Small warehouse that suspends after 60 seconds idle. Auto-suspend stops idle compute use; it does not remove stored tables or other account-level charges.
Check that the warehouse is suspended after a run:
Suspend it manually when finished:
Use the names in your dbt profile if your development resources have different names. Keep GitHub Actions on a separate CI schema and use a non-production role, database, and warehouse.
For reviewing billed credits and hourly warehouse usage, see the Snowflake cost checks guide. Credits are not currency; reconcile account-specific pricing against the invoice or usage statement.
CI execution boundary¶
Pull requests run dbt parse against the placeholder profile in kit/.ci/profiles.yml and do not receive Snowflake secrets. The credentialed build runs only after a push to main, where it executes dbt build against the configured CI schema. Protect main with required review before enabling repository secrets for this workflow. dbt build includes the seed nodes, so the workflow does not need a separate dbt seed step.
Remove development outputs¶
The dbt target schema contains generated views and tables, including the incremental example. Inspect the target before removing it:
Only when DBT_DEV.DBT_DEV is a dedicated disposable development schema and you have confirmed its contents, remove it with:
This permanently deletes every object in that schema. Do not run it against shared or production schemas. It leaves the database, role, and warehouse in place; ask your Snowflake administrator to review those resources separately if you no longer need them.
Incremental order example¶
fct_orders_incremental is disabled in the default build and is a teaching example, not a production-ready CDC pipeline. Enable and build it and its dependencies with dbt build --select +fct_orders_incremental --vars '{enable_incremental_example: true}'. It merges by order_id and reprocesses a three-day window based on source_updated_at. This window must be at least as long as the source's expected update delay; change it when adapting the model. Rows updated outside that window can be missed unless you perform a full refresh.
The first build creates the table. To simulate a correction, update an existing row's amount, status, or source_updated_at in seeds/raw_orders.csv, then reload the seed and rebuild the model:
dbt seed --select raw_orders --full-refresh
dbt build --select +fct_orders_incremental --vars '{enable_incremental_example: true}'
For a complete rebuild of the incremental target:
dbt build --full-refresh --select +fct_orders_incremental --vars '{enable_incremental_example: true}'
The sample uses static CSV data and does not model deletes, event ordering, source outages, or production change-data capture. Decide how to handle those cases before using an incremental strategy with business data.