@kapa.ai Does this mean that if I have a single dbt model (template) that receives parameters like:

dbt build --select orders --vars '{"category_name": "project_1"}'
dbt build --select orders --vars '{"category_name": "project_2"}'
dbt build --select orders --vars '{"category_name": "project_3"}'

In that case, should I create separate Elementary schemas for each parameterized run, or is it acceptable to use a single shared schema? Because Airflow passes different parameters to same model to create project_orders (each order table has different schema) so thats mean that i have a lot of projects but only one order model, so when i pass -vars '{"category_name": "project_1"}' it builds project_1.orders dbt build --select orders --vars '{"category_name": "project_2"}' builds project_2.orders how i should deal with it, does one elementary schema is enough ? (hope so because in future we will have 500 projects so if each project will need to have elementary schema so it will be a nightmare)

This is a very relevant scenario that has been discussed in the Elementary community. Unfortunately, the answer is not the one you're hoping for. The Core Problem Your setup — one dbt project, same model, different

--vars

producing different schemas (e.g.,

project_1.orders

,

project_2.orders

) — is essentially the multi-tenant / schema-per-customer pattern. Elementary's artifacts (like

dbt_models

, run results, etc.) are reloaded/overwritten on each dbt run. This means each parameterized run will override the artifacts from the previous one, causing data loss in Elementary. [Multi-project schema issue] What Elementary Officially Supports Elementary is designed around one Elementary schema per dbt project (per target/env). Since you have one dbt project, in theory one Elementary schema should be enough — but only if the runs don't override each other's artifacts. In your case, since each run changes the schema context via vars, the artifacts will conflict. [Multi-project thread] What the Community Has Tried A very similar use case (same dbt project, different tenant schemas) was discussed directly with Elementary staff. The conclusion was: > "We currently don't support this pattern. You can potentially union elementary tables for overall statistics and build a different report for each customer like you mentioned, but we have no support for it." [Schema-per-customer] The community workaround suggested is: 1. Use a separate Elementary schema per parameterized run (e.g.,

elementary_project_1

,

elementary_project_2

). 2. Create a

union_elementary_schema

— a set of views that

UNION ALL

the Elementary tables from all per-project schemas — and point the

edr

CLI at that union schema for consolidated reporting. [Union stopgap] One important caveat raised by the community: since all runs are from the same dbt project, there may be identifier clashes when unioning. A suggested mitigation is to make the project name dynamic in `dbt_project.yml`:

name: 'my_project_{{ env_var("category_name") }}'

This way, each parameterized run produces distinct identifiers in the Elementary tables. [Identifier clash fix] For Your 500-Project Scale The community has explicitly flagged that this approach does not scale well. One community member with only 5 projects described it as already "cumbersome to maintain." [Community workaround] For your scale (500 projects), Elementary Cloud may be the more viable path, as it supports multiple projects/environments in a single UI without requiring schema consolidation on your end. [Cloud multi-env] In summary: a single shared Elementary schema will not work safely for your parameterized runs as-is, and the union workaround is unsupported and doesn't scale to 500 projects. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai how to check if my artifacts conflicts and over rides everything ? also i dont use edr reports, i need elementary just for his dynamic tests

Great clarification — if you only need Elementary for its dynamic/anomaly detection tests (not

edr

reports or alerts), your situation is actually simpler to manage. Do Artifacts Conflicts Affect You? The artifacts conflict (where

dbt_models

,

dbt_tests

,

dbt_sources

get overwritten on each run) primarily affects: • The Elementary report (lineage, model metadata) • Alerts based on project structure Since you don't use

edr

reports, stale or overwritten metadata in those tables won't break your test results. Test results and run results are stored in separate incremental tables and are not overwritten — they are appended. [on-run-end hooks] What You Should Do You can disable artifact autoupload entirely to avoid the conflict and the performance overhead, while keeping test results flowing normally:

# dbt_project.yml
vars:
  disable_dbt_artifacts_autoupload: true
  disable_dbt_invocation_autoupload: true
  disable_run_results: false
  disable_tests_results: false

This means: • ✅ Elementary dynamic tests still run and results are stored in your DW • ✅ No more artifact conflicts between your parameterized runs • ⚠️

dbt_models

,

dbt_tests

,

dbt_sources

metadata will be stale — but since you don't use the report, this doesn't matter [disable hooks] Checking for Conflicts The knowledge sources don't describe a specific diagnostic command to detect artifact conflicts. However, the symptom is clear: if multiple parameterized runs share the same Elementary schema, the `dbt_models`/`dbt_tests`/`dbt_sources` tables will only reflect whichever run executed last. You can verify this by querying those tables after two different runs and checking if data from the first run is gone. Since you only care about test results, the key tables to verify are

elementary_test_results

and

dbt_run_results

— these are incremental and should retain data across runs. [on-run-end hooks] Bottom line: Disable artifact autoupload, keep test results enabled, and a single Elementary schema should work fine for your use case. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai but all tests looks at elementary schema tables ? so we still will have issue ?

Good question. Let me clarify what the Elementary tests actually depend on. What Elementary Anomaly Tests Actually Use Elementary's anomaly/dynamic tests do not read from the artifact metadata tables (

dbt_models

,

dbt_tests

,

dbt_sources

). Instead, they write to and read from the

data_monitoring_metrics

table — this is where historical metric data is stored for anomaly detection. [anomaly tests discussion] As confirmed by Elementary support: > _"Anomaly tests do not rely on historical results but on historical metrics they already collected on the underlying monitored tables / columns. These are stored in

data_monitoring_metrics

table."_ [anomaly tests discussion] So What's the Risk for Your Setup? The concern is whether multiple parameterized runs sharing one Elementary schema will cause conflicts in

data_monitoring_metrics

. Since this table is incremental (rows are inserted, not replaced), runs for

project_1.orders

and

project_2.orders

will each insert their own metric rows. As long as the monitored table/column identifiers are distinct between runs (e.g.,

project_1.orders

vs

project_2.orders

), they should coexist without overwriting each other. The only real conflict is in the artifact metadata tables (

dbt_models

,

dbt_tests

, etc.) — but since you're disabling artifact autoupload and not using the report, those tables are irrelevant to your use case. Summary For your use case (anomaly tests only, no reports): • ✅ A single Elementary schema should be fine • ✅

data_monitoring_metrics

is incremental and keyed per table/column • ✅ Disabling

disable_dbt_artifacts_autoupload: true

removes the only real conflict risk The knowledge sources don't explicitly confirm this for 500-project scale, so I'd recommend testing with a small number of parameterized runs first to verify no unexpected conflicts arise in

data_monitoring_metrics

. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai so all other elementary tables is used only for edr reports ? test should work fine ?

Yes, that's essentially correct based on what the knowledge sources confirm. What Each Table Category Is Used For Artifact/metadata tables (

dbt_models

,

dbt_tests

,

dbt_sources

,

dbt_exposures

, etc.) are used for: • Elementary reports (lineage, model metadata, coverage views) • Alerts that depend on project structure Run results tables (

elementary_test_results

,

dbt_run_results

,

dbt_invocations

) are used for reports and alerts about test/run outcomes.

data_monitoring_metrics

is the table that anomaly tests actively write to and read from during test execution — this is what powers the anomaly detection logic itself. [anomaly tests discussion] For Your Use Case Since you only use Elementary for its dynamic/anomaly tests, the only table that truly matters for test execution is

data_monitoring_metrics

. The artifact metadata tables are not read by the tests themselves. This is confirmed by Elementary support: > _"Anomaly tests do not rely on historical results but on historical metrics they already collected on the underlying monitored tables / columns. These are stored in

data_monitoring_metrics

."_ [anomaly tests discussion] So with

disable_dbt_artifacts_autoupload: true

set, your anomaly tests should work fine — the artifact conflicts won't affect them. [on-run-end hooks] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai if i wont add these vars: # dbt_project.yml vars: disable_dbt_artifacts_autoupload: true disable_dbt_invocation_autoupload: true disable_run_results: false disable_tests_results: false does my tests still will work correctly ? also what these vars do ?

Yes, your tests will still work correctly without those vars. They are all enabled by default — the vars only exist to disable certain behaviors. What Each Var Does [on-run-end hooks] [reduce on-run-end time] Without These Vars Everything uploads as normal on every run — metadata, invocations, run results, and test results. Your anomaly tests will work fine either way, since they depend on

data_monitoring_metrics

, not on these upload hooks. Why You Might Still Want Them The reason to add these vars (specifically

disable_dbt_artifacts_autoupload: true

) in your case is to avoid the artifact conflict we discussed — where each parameterized run (

project_1

,

project_2

, etc.) overwrites the metadata tables with only the last run's project structure. Since you don't use

edr

reports, this conflict doesn't break your tests, but it does add unnecessary overhead on every run. Bottom line: Skip the vars if you want simplicity — your tests will work. Add

disable_dbt_artifacts_autoupload: true

if you want to reduce run time and avoid the metadata overwrite noise. [on-run-end hooks] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements