If you set

+enabled: "{{ target.name in ['prod'] }}"

for the Elementary package in your

dbt_project.yml

, the Elementary models—and therefore the associated hooks, including the on-run-end hook—will only be enabled and executed when your dbt target is

prod

. In all other target environments, Elementary will be disabled and the hooks will not be invoked. This approach is documented and confirmed in multiple sources, where users and support staff recommend this configuration to ensure Elementary only runs in production and not in other environments such as dev, staging, or CI. For example:

yaml models:   elementary:     +schema: elementary     +enabled: "{{ target.name in ['prod'] }}"

With this configuration, the on-run-end hook will only be triggered when running with the

prod

target, and not for any other target name [FAQ: Can I disable the on-run-end hooks or results uploading?](https://docs.elementary-data.com/oss/general/faq) [Slack discussion: limiting to prod](https://slack.com/archives/C02CTC89LAX/p1678377959148139) [Slack discussion: disabling outside prod](https://slack.com/archives/C02CTC89LAX/p1678899522071399).

There is some anecdotal information about the performance impact of Elementary in the knowledge sources. One user reported that the on-run-end hooks took approximately 6 seconds for a run of 4 models and about 12 seconds for 48 tests on those 4 models. The Elementary team confirmed that the runtime of the on-run-end hooks is directly related to the number of models and tests included in the run, as the size of the results object affects processing time. They also mentioned efforts to be efficient, such as not running certain macros if there are no tests and minimizing the number of insert queries. However, there is no comprehensive benchmark or official documentation on performance impact beyond these user reports and general guidance [Slack discussion on performance](https://slack.com/archives/C02CTC89LAX/p1664996355098769). If you need more detailed or specific performance metrics, the knowledge sources do not provide them.

If you set

+enabled: "{{ target.name in ['prod-test'] }}"

for Elementary, then Elementary models and hooks (including test result collection and artifact uploads) will only be active when you run dbt with the

prod-test

target. Regarding your specific questions: - Will the tables still be populated when the workflow runs tests only? Yes, as long as you run dbt with the

prod-test

target and Elementary is enabled, the tables will be populated with test results and artifacts during

dbt test

or

dbt build

runs. However, if you run with any other target, Elementary will not be active, and the tables will not be updated or populated. - Would the tables get rebuilt? The Elementary models (tables) are only rebuilt when you explicitly run

dbt run --select elementary

(or as part of a

dbt build

that includes Elementary models) with the

prod-test

target. If your workflow only runs tests (e.g.,

dbt test

) and does not include a model build step, the tables will not be rebuilt—only populated with new test results if they already exist. If the tables do not exist (for example, on a fresh environment), you must first run

dbt run --select elementary

with the

prod-test

target to create them. This is confirmed in support discussions where users encountered errors when the Elementary tables did not exist and were advised to run

dbt run --select elementary

first [Slack: Unable to insert rows to non-existent table](https://slack.com/archives/C02CTC89LAX/p1677164475554009). In summary: - With

+enabled: "{{ target.name in ['prod-test'] }}"

, Elementary only works for the

prod-test

target. - Tables are only rebuilt if you run the Elementary models. - If you only run tests and the tables already exist, they will be populated; if not, you need to build them first.