Zendesk for StartupsUp to 2 years free for startups + AI Agents & Copilot
Promoted
Launched this week
Relium
Catch risky dbt changes before they break business metrics
33 followers
Catch risky dbt changes before they break business metrics
33 followers
Relium is a pre-merge reliability layer for SQL and dbt. It reviews every PR, understands semantic changes, traces downstream model and KPI impact, checks warehouse evidence, and returns ALLOW / WARN / BLOCK before production. Unlike observability tools that alert after data breaks, Relium helps teams catch silent logic failures before they ship.
@abhishekh2 Not dbt on my side, just plain SQL over a job index, but the failure you describe is the one that got me. I tightened the query that decides whether a posting belongs to our industry at all, every check passed, and the next weekly report had one country losing a big share of its openings. Part of that drop was correct, junk we never should have counted, and part was the new condition quietly excluding companies with no country set. What would earn my trust is less the ALLOW/WARN/BLOCK label and more a handful of concrete rows that moved in each direction, so I can tell in a minute which side is the bug. A bare verdict I would probably learn to click through within a week. When a change touches millions of rows, how do you pick which ones to show, the biggest contributors to the metric or the rows the diff logic hits directly?
@antonkylikov That’s exactly the kind of failure mode I’m trying to make visible. A bare verdict isn’t enough if you can’t quickly inspect the evidence behind it.
Right now Relium focuses on the semantic diff, downstream impact, and warehouse evidence around the change. The direction I’m pushing toward is showing representative affected rows alongside the verdict so you can answer what actually changed without digging manually.
For large changes, I would want a mix of both: rows directly affected by the changed logic, plus rows that contribute most to the downstream metric movement. That feels more useful than sampling randomly.
Your example is really helpful especially the “learn to click through within a week” point. That’s exactly the failure mode I want to avoid.
@abhishekh2 the mix makes sense, but the rows that actually hurt me would have slipped past both. they were companies with no country set, each one tiny, so none of them showed up as a top contributor, and the diff logic didn't touch them directly either, they just stopped matching a join. it was only the count that was big. i ended up grouping moved rows by which column was null before looking at any samples at all. do you treat nulls as their own bucket in the evidence, or is that left to whatever tests the team already has