Elementary OSS: dbt-native data observability, reviewed before you adopt it

What Elementary OSS actually solves for a dbt team

A dbt project already produces a lot of signal: test results, run results, timing per model, and the manifest that describes your DAG. Most teams see that signal once, in a terminal, and then lose it. The next morning nobody can say whether the orders model has been slow all week or whether a freshness check has been quietly failing since Friday. Elementary OSS exists to keep that history and put it in front of you.

The audience is narrow and stated plainly. The README calls it the open-source CLI for dbt-native data observability, and pyproject.toml describes the package as data monitoring and lineage with warehouse keywords for Snowflake, BigQuery and Redshift. If your transformations do not run through dbt, the tool has nothing to read. That is not a limitation to work around; it is the design.

The package is Apache-2.0 licensed and published as elementary-data on PyPI, with the CLI entry point named edr. The README also points at a companion repository, the Elementary dbt package, and the two are meant to be installed together.

The mechanism: warehouse metadata plus dbt artifacts, read by the CLI

The README describes the flow in a few lines. Elementary OSS connects to your warehouse and reads the metadata, artifacts and test results collected by the Elementary dbt package. From that it generates a report, surfaces anomalies and failed tests, sends alerts to Slack and Microsoft Teams, and tracks model and test performance trends.

The important consequence is that the CLI is a reader, not a collector. The dbt package does the collecting during your dbt runs, writing metadata and run results as part of those runs (the README lists a dbt artifacts uploader among the features). If the package is not installed in the dbt project, or if dbt never runs, the CLI has no fresh input. This split is why the quickstart walks through both pieces rather than just a pip install.

Configuration follows the same logic. The README lists configuration-as-code as a feature and says Elementary configuration is managed in your dbt code. There is no separate dashboard config file to maintain, which is convenient for version control and awkward if you expected a UI to configure monitors. Anomaly detection is expressed as native dbt tests, so the same test selection syntax and CI habits you already use apply. Alerts support custom channels and tagging of owners.

Installing the CLI and running a first report

The README does not inline install steps; it links to the quickstart guide at docs.elementary-data.com/oss/quickstart and states that the guide covers installing and configuring both the Elementary dbt package and the CLI. The package name and version come from pyproject.toml, which declares elementary-data at version 0.26.0 and a Python requirement of >=3.10,<3.14.

Install the CLI first:

pip install elementary-data

The console script installed by that package is edr, which the Dockerfile also uses as its ENTRYPOINT. Running it with no arguments prints the available commands; the report generation command is the one the quickstart builds up to.

The Python version constraint is real and worth checking before you install. pyproject.toml lists classifiers for 3.10 through 3.13 and a dependency of python = ">=3.10,<3.14", so a 3.9 interpreter will not resolve the package.

The dbt side is a separate install, done as a package inside your dbt project rather than with pip. The repository does not show a packages.yml, so take the package name and version from the Elementary dbt package repository. After adding it, run dbt deps and then a dbt run so the package writes its models and collects results, then point the CLI at the same profile and generate the report.

If you prefer containers, the repository ships a Dockerfile that installs the package with all extras and sets edr as the entry point. It defines DBT_LOG_PATH and DBT_TARGET_PATH under /usr/app, which is where the artifacts are expected to live inside the image.

Where Elementary OSS stops and the cloud product starts

The README is unusually direct about the boundary, and it is the single most important thing to understand before adopting. Elementary OSS generates the basic observability report and sends alerts to Slack and Teams. Everything beyond that is described as part of Elementary Cloud: automated ML monitoring, column-level lineage from source to BI, a built-in catalog, and AI agents.

Some features in the list are therefore ambiguous about which product delivers them. End-to-end data lineage appears as a feature, immediately followed by a sentence that column-level lineage from ingestion to BI is a cloud offering, so the OSS lineage is presumably model-level and enriched with the latest test results. Automated monitors are described as out-of-the-box cloud monitors. That wording suggests freshness, volume and schema monitoring are not fully available in the open-source path, even though the README lists them without a cloud qualifier in the heading.

This is a deliberate open-core split, and it is not dishonest, but it means the free tool is a reporting and alerting layer over dbt tests rather than a monitoring platform. If you want anomaly detection without writing tests, the OSS path expects you to define those tests in dbt yourself.

The dbt dependency is the failure mode

The wrong tool for a team that does not use dbt is the obvious case, and it is worth stating because the project name gives no hint. There is no ingestion path for a Spark job, an Airflow DAG that does not call dbt, or a hand-written SQL pipeline. The artifacts the CLI reads are dbt artifacts.

A subtler failure mode is drift between the two halves. Because the dbt package collects and the CLI reads, a version mismatch between the installed CLI and the dbt package can leave the report empty or incomplete, and the README does not document a compatibility matrix between the two. The quickstart guide is the place to check, and it is linked rather than reproduced in the repository.

There is also a dependency floor worth noticing. pyproject.toml pins dbt-core to >=1.8,<3.0.0 and includes a comment that from 2.0, dbt-core is the Fusion engine requiring Python >=3.11, with adapters built into the engine. A team still on an older dbt 1.x release, or one planning to move to the 2.x line, should read that comment before assuming the same install works on both sides of the boundary.

Finally, the repository itself is mostly HTML by language statistics, which reflects the report assets rather than the Python CLI. If you are evaluating the codebase for contribution, look in the elementary directory, not at the language breakdown.

How it compares with running dbt tests plus a BI dashboard

The realistic alternative for many small teams is not another observability vendor. It is dbt test results written to a table, plus a dashboard built on top of them, plus a Slack integration that already exists for CI failures.

That approach gives you full control and no extra dependency. What it does not give you cheaply is the assembled view: a report that joins test results with run timing and warehouse metadata, an anomaly test library expressed as native dbt tests, and model performance tracked over time. Elementary OSS packages those into one install. The trade is that you inherit its version cadence and its open-core boundary.

The comparison with a commercial data observability platform is a different trade. Those platforms generally monitor without requiring dbt, which is the whole point for teams with mixed pipelines. Elementary OSS inverts that: it is cheap and close to your existing dbt workflow, and it is useless outside it. Pick based on where your transformations actually run, not on feature lists.

Maintenance, versioning and licence in practice

The repository is not archived and the last push was on 2026-09-28. Releases are frequent: v0.26.0 on 2026-09-10, v0.25.1 on 2026-07-08, and v0.25.0 on 2026-06-21, which suggests a roughly monthly cadence in the recent record. That cadence matters for upgrade cost, because a CLI that reads artifacts produced by a dbt package is sensitive to version skew, and the README does not publish a compatibility table.

The dependency pins in pyproject.toml are unusually explicit and worth reading before an upgrade. Several transitive dependencies are floored rather than capped, with inline comments naming the advisories they address: idna >=3.15 for a ReDoS in idna.encode(), pyasn1 >=0.6.4 for decoder denial-of-service advisories, and cryptography >=50.0.0 for a PKCS#7 oracle. Those floors mean an old lockfile may not satisfy them, so expect to refresh dependencies when you bump the CLI.

Licensing is Apache-2.0 for the CLI package, per both pyproject.toml and the README badge. The README does not state the licence of the separate dbt package repository, and it does not describe what happens to the OSS feature set if the cloud product changes. Those are the two licence-adjacent questions to settle with your own legal review rather than from the repository.

Editorial conclusion

Adopt Elementary OSS if your transformations already run through dbt and you want test results, freshness and model run history in one report without buying a platform. Do not adopt it if your pipeline does not produce dbt artifacts, or if you need column-level lineage from ingestion to BI, which the README attributes to Elementary Cloud. Verify first that your dbt version falls inside the declared range of >=1.8,<3.0.0 in pyproject.toml, that your Python interpreter is 3.10 through 3.13, and that the Elementary dbt package is installed alongside the CLI, since the CLI reads what that package collects.

Frequently asked questions

Official sources

1. elementary-data/elementary on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases