A dbt project on GitHub
Relium looks for a dbt_project.yml in the repositories your GitHub App installation authorises. It can live at the repository root or in a subdirectory.
How it works
What Relium does between the pull request and the merge.
Relium is a pre-deployment verification system for data changes. It reads the change, works out what it would do to everything downstream, weighs the evidence it can gather, and returns a decision — all before the change reaches production.
The review
Step by step, on the pull request.
Everything below happens on the pull request. Nobody has to open a dashboard for it to work.
Relium sees the change
The Relium GitHub App is installed on the repositories you choose. When a pull request touches SQL or dbt files, Relium opens a review for that commit.
Your CI submits the compiled manifests
A GitHub Actions step runs dbt compile for the base and head commits and posts both manifests to Relium, authenticated with a repository secret. Reading the compiled project rather than the raw diff is what lets Relium reason about the real dependency graph — including everything a macro or a ref expands into.
It computes the change plan
Which models changed, and how the compiled SQL differs between the two commits. This is a structural comparison, not a text diff: reformatting a query is not a change to what it means.
It traces the blast radius
From the manifest's own lineage: the direct downstream models, the sources feeding in, and the exposures — dashboards and reports your dbt project already declares.
It evaluates semantic risk
Join semantics and filter placement, null handling, cardinality changes, contract breaks, and changes to the definitions your KPIs are computed from. This is the part a schema test cannot do: the shape of the output can be identical while the meaning has moved.
It weighs the evidence it has
Where a warehouse collector is connected, Relium requests bounded aggregate metadata for the affected tables — row counts, distinct and duplicate key counts, null rates, freshness — and compares it against the change. Where no evidence is available, the review says so rather than assuming.
It publishes the decision
One check run and one comment on the pull request, reconciled rather than duplicated on every push. The dashboard holds the full report: the reasoning, the findings, the affected assets and the evidence behind each one.
Rollout
Shadow first, enforce when you are ready.
Relium starts in shadow mode on every repository. The decision is real and it is published, but a WARN or a BLOCK stays advisory and does not fail the GitHub check.
Shadow mode
Relium publishes the decision on every pull request. Your team can read it, disagree with it, and calibrate against it — without a single merge being held up. This is the right place to start, and many teams stay here for weeks.
Default on every repository
Enforce mode
A BLOCK decision fails the GitHub check, so branch protection holds the merge until the finding is resolved or a reviewer records an exception. WARN stays advisory in both modes.
Merge blocking is included on Pro
Requirements
What you need before you start.
Three things, and you almost certainly have all of them.
A CI job that can compile it
If you already run dbt compile or dbt build in CI, you are done. Relium gives you the exact workflow step and the one repository secret it needs.
Optionally, a warehouse
Warehouse evidence sharpens the decision but is not required to get one. The collector runs in your environment with your own read-only credentials, and is available from the Starter plan.
Get started
Know what changes before you ship.
Connect a repository and open your next pull request. Relium will review the change and publish its decision on the PR.
- Free plan, no card required