@kapa.ai can you give me information on what each table/view contains in the elementary schema ?

Here's an overview of the key tables and views in the Elementary schema, based on the available knowledge sources: Incremental Tables (persist data over time) elementary_test_results Stores the results of all dbt tests (native dbt tests, Elementary tests, and third-party package tests). Each row represents a single test execution, including pass/fail status, metadata, failed row samples (up to 5 by default), and the generated test SQL query. New data is loaded via the

handle_tests_results

on-run-end hook. [package models] test_result_rows Stores individual failed sample rows, one row per sample. Linked to

elementary_test_results

via

elementary_test_results_id

. Useful for inspecting specific failing records. Also contains detailed data for anomaly tests, including metrics and anomaly scores used in the Elementary report graphs. data_monitoring_metrics Stores historical metric values (e.g., row counts, freshness, column statistics) over time, bucketed by time period. This is the core table that anomaly detection tests write to and read from during execution. Updated via the

handle_test_results

on-run-end hook. [package models] dbt_models Stores metadata about dbt models in your project (model name, unique ID, materialization type, dependencies, description, etc.). Updated using hash-based change detection — only refreshed when the project actually changes. dbt_sources Stores metadata about dbt sources defined in your project. dbt_tests Stores metadata and configuration for all dbt tests defined in your project (test definitions, not results). dbt_source_freshness_results Stores source freshness check results over time. schema_columns_snapshot Stores a snapshot of column-level schema metadata for monitored tables. alerts_v2 Elementary's central alert tracking table (introduced in v0.14.0). Stores all pending and sent alerts across all alert types (test failures, model errors, source freshness issues). Each row includes a

data

JSON column with rich alert context. [alerts_v2 info] Views (computed on the fly) metrics_anomaly_score A view on

data_monitoring_metrics

that runs the same anomaly scoring query the tests use. Provides visibility into anomaly detection results, including fields like

full_table_name

,

column_name

,

metric_name

,

metric_value

,

training_avg

,

training_stddev

,

training_set_size

,

anomaly_score

,

is_anomaly

,

bucket_start

,

bucket_end

,

min_metric_value

,

max_metric_value

. [package models] anomaly_threshold_sensitivity A view on

metrics_anomaly_score

that calculates whether recent metric values would have been flagged as anomalies at different anomaly score thresholds. Useful for tuning the

anomaly_score_threshold

parameter. [package models] monitors_runs A view on

data_monitoring_metrics

used to determine when a specific anomaly detection test was last executed. Each anomaly test queries this view to decide the start time for collecting new metrics. [package models] dbt_artifacts_hashes A view used for change detection on artifact metadata tables. Stores a hash of each artifact model's metadata; Elementary compares current hashes to stored ones to decide whether to refresh artifact tables. [artifacts hashes] alerts_anomaly_detection, alerts_dbt_tests, alerts_schema_changes, alerts_dbt_source_freshness, alerts_dbt_models Views that surface alerts for specific alert categories (anomaly detection, test failures, schema changes, source freshness, model errors respectively). job_run_results, model_run_results, snapshot_run_results Views providing run result summaries for jobs, models, and snapshots respectively. > Note: Elementary does not publish a formal ERD or complete foreign-key map. The best authoritative reference for field-level details is the dbt_artifacts.yml file in the open-source repo, combined with direct inspection of your warehouse schema. [data model overview] 👍 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 When the disable_artifact_autoupload is paused what tables/views don't get updated ?

When

disable_dbt_artifacts_autoupload: true

is set, only the metadata (artifacts) tables stop being automatically updated via the

on-run-end

hook. Specifically, these tables will no longer be refreshed automatically: •

dbt_models

•

dbt_tests

•

dbt_sources

•

dbt_exposures

•

dbt_metrics

•

dbt_snapshots

•

dbt_seeds

•

dbt_columns

•

dbt_groups

[dbt artifacts; on-run-end hooks] What still gets updated normally: The following run results tables are unaffected and continue to be populated by the

on-run-end

hook: •

elementary_test_results

•

dbt_run_results

•

dbt_invocations

•

model_run_results

,

snapshot_run_results

,

seed_run_results

,

job_run_results

•

dbt_source_freshness_results

•

data_monitoring_metrics

(written to by anomaly tests, not the hook) [on-run-end hooks] To disable those result tables as well, you would need to set additional variables:

vars:
  disable_run_results: true
  disable_tests_results: true
  disable_dbt_invocation_autoupload: true

[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.