Can I configure Elementary tables to be append-only?

It depends on which Elementary tables you're referring to, as they fall into two distinct categories: Tables that are already incremental (append-only by design) Several Elementary tables are already incremental and append new rows on each run: •

dbt_run_results

•

dbt_invocations

•

model_run_results

•

elementary_test_results

•

data_monitoring_metrics

These tables grow over time and have no built-in retention policy. [Lifecycle & growth] Tables that are NOT append-only (by design) Some artifact tables are replaced/overridden on each run — this is intentional: •

dbt_models

•

dbt_tests

•

dbt_sources

•

dbt_exposures

•

dbt_metrics

These tables are overwritten with the latest state of your project on every

dbt run

or

dbt build

. This behavior is by design and cannot be changed to append-only through configuration. [Lifecycle & growth] Managing growth of incremental tables Since the incremental tables grow indefinitely, you are expected to manage their size yourself. The recommended approach is to delete old rows using a date column like

created_at

or

updated_at

. There is no built-in auto-pruning or partitioning config. [Lifecycle & growth; Managing incremental tables] > ⚠️ Be careful to only delete or archive rows — do not alter columns or constraints, so Elementary's incremental logic continues to work correctly. 👍 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 Is there a way to configure in my yaml to make elementary artifacts table to be append only?

Based on the knowledge sources available, there is no YAML configuration option to make Elementary's artifact metadata tables (

dbt_models

,

dbt_tests

,

dbt_sources

, etc.) append-only. This behavior is by design — these tables always reflect the latest state of your dbt project, not its history. As explained by Elementary support: > "The artifact models (

dbt_*

) behave like tables, not incremental models. At every point in time, they only hold the latest state of your dbt project, not its history." [dbt artifacts behavior] The incremental materialization used internally is purely for efficiency (delete + insert only changed rows), not for historical accumulation. [dbt artifacts behavior] What you can configure in YAML is when these tables are updated:

vars:
  disable_dbt_artifacts_autoupload: true

This stops the

on-run-end

hook from updating the metadata tables on every run, but it doesn't make them append-only — it just means they'll only be updated when you explicitly run:

dbt run --select elementary.edr.dbt_artifacts

[Control On-Run-End Hooks] If you need historical tracking of models and tests over time, the recommended approach is to use the run results tables (

dbt_run_results

,

model_run_results

), which are already incremental and accumulate history by design. [dbt artifacts behavior] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

what if i do smth like @kapa.ai

elementary:
artifacts:
materialized: full_refresh

Setting

materialized: full_refresh

(or any custom materialization override) on Elementary's artifact models is not a supported or documented configuration in the knowledge sources available to me. More importantly, it wouldn't achieve append-only behavior —

full_refresh

is the opposite of what you want. It would cause Elementary's incremental tables (like

elementary_test_results

,

dbt_run_results

, etc.) to be wiped and rebuilt from scratch on every run, destroying historical data. [Package full refresh] In fact, Elementary specifically protects against this by not honoring the standard

--full-refresh

flag on its incremental models by default. To actually trigger a full refresh of Elementary tables, you'd need to explicitly set

elementary_full_refresh: true

. [Package full refresh] To summarize: • There is no YAML config to make artifact tables (

dbt_models

,

dbt_tests

, etc.) append-only. • Overriding the materialization is not recommended and could break Elementary's internal logic. • For historical tracking, use the already-incremental tables like

dbt_run_results

or

model_run_results

. [dbt artifacts behavior] 👍 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 IM sorry, I mean append only

No worries! But the answer remains the same — there is no YAML configuration to make Elementary's artifact metadata tables (

dbt_models

,

dbt_tests

,

dbt_sources

, etc.) append-only. As confirmed by Elementary support, these tables are designed to always reflect only the latest state of your dbt project: > "The artifact models (

dbt_*

) behave like tables, not incremental models. At every point in time, they only hold the latest state of your dbt project, not its history." [dbt artifacts behavior] There is no supported

append_only

or equivalent setting for these tables in

dbt_project.yml

or any other Elementary configuration file. The knowledge sources do not document any such option. If you need historical data accumulation, the tables that already behave as append-only (incremental) are: •

dbt_run_results

•

model_run_results

•

dbt_invocations

•

elementary_test_results

These are the recommended tables for tracking history over time. [Managing incremental tables] 👍 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 Alerts tables are which type of materialization?

Based on the knowledge sources, Elementary's alert tables are incremental models. Specifically: •

alerts

(or

alerts_v2

in newer versions) •

alerts_models

•

alerts_source_freshness

These are all materialized as incremental tables (using MERGE or INSERT strategies depending on the warehouse). You can see this confirmed in multiple run logs, for example: >

1 of 3 START sql incremental model elementary.alerts

>

1 of 1 START sql incremental model elementary.alerts_v2

[alerts incremental; alerts_v2 incremental] These tables are used to track alert state (e.g., which alerts have been sent vs. pending). If they are dropped and recreated instead of updated incrementally, it can cause already-sent alerts to be resent — which is a known issue when something disrupts the incremental behavior. [alerts state issue] 👍 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 Artifacts hashes are used for what?

The

dbt_artifacts_hashes

table/view is used by Elementary as a change detection mechanism for artifact metadata tables. Specifically, it stores a hash of the metadata for each artifact model. When Elementary runs, it compares the current metadata hash against the stored hash to determine whether a given artifact model has actually changed and needs to be updated. If nothing has changed in the project, Elementary will skip updating those artifact tables — this is why

dbt_models

,

dbt_tests

, etc. may not refresh on every run even if you run

dbt run --select elementary

. [artifacts hash behavior] As one community member explained: > "Elementary 0.15 updates models only when required. It uses hashes (AFAIK built-in DBT model hashes) to detect if a model was changed. So if you don't change anything in a project - Elementary will skip some (or even all) DBT artifacts." [artifacts hash behavior] The

dbt_artifacts_hashes

itself is a view (not a table) by default. A known issue is that if you accidentally override it to be an incremental table (e.g., via a project-level

+materialized: incremental

config), it can accumulate duplicate rows and slow down execution. The fix is to revert it back to a view. [artifacts hashes duplicates] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.