Column-level data monitoring for dbt teams.
Every test passed. The number in the board deck was still wrong.
dbt tests assert the bounds somebody wrote down, so they catch a pipeline that breaks. They say nothing about a pipeline that keeps running and quietly produces wrong numbers. Pipeline Sentinel watches every column statistically and tells you the night the distribution changed.
Fifteen column checks, one injected schema change, detection computed live in your browser, with the dbt suite passing throughout.
The problem
Assertions catch breakage. Silent wrongness is the expensive failure.
not_null, accepted_values, unique, row_count > 0. Every one of them encodes a rule a person thought of in advance, about a column that person remembered. An upstream vendor changes a source schema and a column starts arriving null one row in eight. A join grain shifts and the fact table quietly fans out. A currency field switches unit. None of that trips an assertion. The run is green, the dashboard is live, and the number is wrong until somebody senior notices in a meeting.
The insight
The category is proven. The gap is who can afford it and whether you can leave it on.
Monte Carlo, Anomalo, and Bigeye did the hard work of convincing the market that data observability is a real budget line, and they price and sell for the enterprise. The team that needs this most is the ten-person data org on dbt and Snowflake with a warehouse bill and no observability budget, and they get offered a six-figure contract with a sales cycle. That is the commercial gap. The technical gap is more interesting: monitoring at column granularity means thousands of simultaneous tests every run, and thousands of tests at any fixed significance level produce false alarms by arithmetic, not by bad luck. Teams do not turn these tools off because the detection is bad. They turn them off because nobody built the multiplicity control that makes column-level granularity survivable.
CUSUM on day-over-day percentage changes and Bayesian Online Changepoint Detection (Adams & MacKay 2007) per column per check, then Benjamini-Hochberg FDR control across every test in the run, so the alert budget is set once, globally, instead of per-test thresholds that each look reasonable and collectively flood the channel.
How it works
Four steps, no data science team
It reads manifest.json and run_results.json for the DAG and the run history, then profiles the models themselves. No new modelling layer, no YAML to write per column.
Freshness, row count, null rate, distinct-count ratio, and distribution shape per column per model. The history builds itself from the runs you already do.
Every column-check series goes through CUSUM and BOCD. Benjamini-Hochberg then filters across the entire run, so you set one false-discovery rate for the warehouse instead of tuning thousands of thresholds you will never revisit.
Plus the DAG neighbourhood: which downstream models and exposures consumed the bad grain, so you know what to recompute and who to tell before they quote it.
Who it is for
The analytics engineer who gets asked why the number changed
Mid-market data teams on dbt with a cloud warehouse: usually 3 to 15 analytics engineers, enough models that nobody holds the DAG in their head, and at least one incident where a number was wrong for a fortnight before anyone caught it.
Pricing
- –Full detection engine
- –All five column checks
- –Slack alerts
- –30-day history
- –Unlimited columns and checks
- –DAG-aware downstream impact
- –FDR budget per project
- –12-month history
- –dbt Cloud and Airflow hooks
- –Self-hosted option
- –Custom checks
- –SSO and audit log
- –Warehouse cost controls on profiling
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Monte Carlo | The category leader. End-to-end data observability with lineage across the whole stack. | Six-figure contracts and an enterprise sales cycle. A ten-person data team is not a customer they are trying to win, and dbt is one integration among many rather than the substrate. |
| Anomalo | ML-based data quality monitoring with unsupervised table checks. | Same enterprise motion and price band. Sits beside dbt as another system rather than reading the DAG you already maintain. |
| Bigeye | Metric monitoring with autothresholds across warehouse tables. | Autothresholds are per-metric bands. That is exactly the design that produces steady alert volume at column granularity, because nothing accounts for how many bands you are evaluating at once. |
| Elementary | Open-source dbt-native observability with anomaly detection on test results. | Closest on dbt-nativeness and the right instinct. The detection is z-score against a rolling window per test with no correction across the run, so alert volume is the reason teams end up narrowing it to a handful of tables. |
| dbt tests and Great Expectations | Assertions you write, run in the pipeline, free. | They check what you predicted. Every failure mode in this product is one nobody predicted, which is why the suite is green while the number is wrong. |
This is the most crowded category of the ten, and that is not a detail to bury. Monte Carlo, Anomalo, and Bigeye are all well funded, all have real engineering teams, and any of them could ship an SMB tier tomorrow and take the price wedge away. Elementary already owns the dbt-native position with an open-source distribution we would have to out-execute rather than out-position. The wedge here is not a capability nobody has; it is price, being genuinely inside dbt instead of adjacent to it, and being the one that stays on because the statistics make column-level granularity survivable. That is a narrow claim, and if a well-funded incumbent decides the mid-market is worth their sales cost, being right about FDR control will not be enough on its own.
Market
Priced against the warehouse bill, not the enterprise observability budget
Tens of thousands of companies run dbt in production, the large majority of them well below the floor the enterprise vendors sell to. Five thousand of them at the Team tier is $36M ARR, and the deciding factor is that the buyer can approve $600 a month on a card without a procurement cycle.