Elementary.

What Elementary actually is

Elementary is a dbt package plus a web UI that reads dbt’s own artifacts — manifest.json, run_results.json, sources.json — and turns them into an observability surface: test results over time, freshness and volume anomalies, model-level lineage, and schema change detection. The architecture matters because it constrains what Elementary can and cannot see. Anything dbt touches, Elementary observes. Anything upstream of dbt — Fivetran loads, custom ingestion scripts, raw warehouse tables written by application code — is invisible.

This is a deliberate design choice, not a limitation. The bet is that most analytics-engineer teams spend most of their debugging time inside the dbt graph anyway, and that a tool which lives in the same codebase, runs in the same CI pipeline, and fails the same pull requests is worth more than a more comprehensive tool that lives elsewhere.

Where it fits against the alternatives

Against dbt-expectations and Great Expectations, Elementary is the obvious upgrade path. Both of those are assertion libraries; Elementary is an assertion library plus an anomaly detection engine plus a UI plus an incident workflow. Teams usually adopt Elementary after hitting the limits of manually-authored dbt tests — specifically, the “we can’t pre-specify every failure mode” limit that ML anomaly detection is designed to solve.

Against Monte Carlo, Elementary trades breadth for depth. Monte Carlo monitors the warehouse itself and catches issues regardless of pipeline. Elementary only sees dbt. Teams that move from Elementary to Monte Carlo typically do so when their data platform grows beyond a single dbt project — multiple data teams, ingestion outside dbt, streaming. Teams that stay with Elementary do so because their value is concentrated in the dbt graph and they prefer the cost model of OSS plus a lighter managed tier.

Against Metaplane and Bigeye, Elementary is the code-first, dbt-shaped option. Metaplane and Bigeye are warehouse-native with strong automatic monitoring but less integration with the analytics-engineer workflow. If your team’s gravity is in the dbt project, Elementary feels native. If it’s in the warehouse console, Metaplane/Bigeye feel native. Either preference is defensible.

Against Datafold, there is less overlap than surface appearances suggest. Datafold’s core value is pre-merge diffing — showing what a model change will do to production output before it ships. Elementary’s core value is post-merge monitoring — telling you when production is broken. Mature teams often run both.

Notable gotchas

Anomaly detection requires a training window. The docs recommend 30 days; in practice, highly seasonal tables (weekly patterns, month-end spikes, marketing campaign surges) will produce false positives until the model has seen enough history. Plan for a two-week tuning period.

The OSS version stores its elementary tables in your warehouse, which means warehouse cost. Not much — it’s essentially log data — but worth knowing if you’re on a consumption plan.

Alerts fan out on every test failure by default. Teams that skip the exercise of grouping tests by owner and severity end up with Slack channels that get muted. Budget an afternoon for alert routing configuration before rollout.

How to evaluate it

The honest test: install the OSS package in a staging dbt project, connect it to a real warehouse, and let it run for two weeks. If the anomaly detection surfaces real issues your existing tests didn’t catch, the tool is working for you. If it mostly surfaces false positives on expected seasonality, your data is too irregular for the model and you should look at warehouse-native options instead.