You can prevent Elementary's pre- and post-hooks from running in your dev (or other non-prod) environments by configuring your dbt project to disable Elementary based on the target environment. This is a common approach for teams who want to avoid the overhead of Elementary hooks during local development or non-production runs. Option 1: Disable the entire Elementary package in non-prod environments Add this to your

dbt_project.yml

under the

models

section:

yaml models:   elementary:     +enabled: "{{ target.name == 'prod' }}"

This will ensure Elementary models (and thus its hooks) only run when your dbt target is

prod

[see example](https://slack.com/archives/C02CTC89LAX/p1674814915518089). Option 2: Disable only the hooks using variables If you want more granular control (e.g., keep Elementary models available but skip the hooks), add the following to your

dbt_project.yml

under `vars`:

yaml vars:   disable_run_results: "{{ target.name != 'prod' }}"   disable_tests_results: "{{ target.name != 'prod' }}"   disable_dbt_artifacts_autoupload: "{{ target.name != 'prod' }}"   disable_dbt_invocation_autoupload: "{{ target.name != 'prod' }}"

This disables the Elementary hooks in any environment where the target is not

prod

[see example](https://slack.com/archives/C02CTC89LAX/p1674814915518089). Option 3: Pass variables via CLI for ad-hoc runs For one-off runs, you can also pass the disabling variable directly in your CLI command:

sh dbt run --vars '{"disable_dbt_artifacts_autoupload": true}'

This will skip the artifact upload hook for that run only [see example](https://slack.com/archives/C02CTC89LAX/p1711555630207219). Note: - Make sure your

target.name

values match your actual environment names (e.g.,

dev

,

prod

, etc.). - Disabling the entire package will also remove Elementary models from your manifest, which may cause issues if you reference them elsewhere. If you need the models but just want to skip the hooks, use the variable-based approach. Let me know if you need help with a specific setup!

@kapa.ai what happens when i "dbt run -s elementary"? Does it erase historic data?

Running

dbt run -s elementary

builds or updates the Elementary tables in your data warehouse. This command is typically used after installing or upgrading the Elementary dbt package to ensure that all necessary tables and schema changes are applied. Importantly, running

dbt run -s elementary

does not erase historic data from the incremental models. The main purpose is to create or update the tables as needed, such as when new columns are added in a package upgrade. Your historical data in incremental tables (like test results and run results) will be preserved, unless you have overridden the materialization settings in your

dbt_project.yml

(e.g., setting

+materialized: table

instead of the default incremental) or run with a full-refresh flag, which would clear the data. This behavior is confirmed in several community discussions: - "No, you will lose no data." (in response to whether running

dbt run -s elementary

daily would cause data loss) [see discussion](https://slack.com/archives/C02CTC89LAX/p1687967765734029) - "It will just make sure that they have all the necessary columns" (in response to whether running after an upgrade would replace previous tables) [see discussion](https://slack.com/archives/C02CTC89LAX/p1708505470238349) - "The execution is not supposed to delete the data from the incremental models." (unless materialization is overridden) [see discussion](https://slack.com/archives/C02CTC89LAX/p1653308392841579) Summary: -

dbt run -s elementary

is safe for historical data in incremental models. - Data loss can occur only if you run with

--full-refresh

or override materialization to

table

in your config.