dbt-expectations.
Founded 2020
Status · ● active
Open-source dbt package adding 50+ Great Expectations-style assertions as native dbt tests that run in your own warehouse.
Where it fits — and where it doesn't.
dbt-centric analytics-engineering teams that already run dbt test in CI and want a broad library of declarative, in-warehouse assertions — value ranges, regex and pattern matching, schema shape, and distributional bounds (mean, median, stdev, quantiles) — with zero added cost or infrastructure. It is the natural first step up from dbt's four built-in tests (unique, not_null, accepted_values, relationships) for a team that wants richer checks without leaving the dbt workflow.
You need ML-based anomaly detection, learned thresholds, automatic freshness or volume baselines, lineage, incident management, or alerting out of the box — dbt-expectations has none of these; it emits pass/fail and nothing else. It is also not for teams that aren't on dbt at all.
The honest scorecard.
- Free and Apache-2.0 with no paid tier, no SaaS, and no lock-in — the only cost is your own warehouse compute
- A library of 50+ assertions far beyond dbt's four built-ins (value ranges, regex, schema shape, distributional bounds)
- Fully native to dbt — declared in YAML, run by dbt test / dbt build, inheriting dbt severity levels, CI, and run artifacts; the current fork release is dbt Fusion-compatible
- Push-down execution across Postgres, Snowflake, BigQuery, DuckDB, Spark, and Trino
- No ML or anomaly detection and no learned baselines — every threshold is hand-specified, so it cannot catch unknown-unknowns
- No alerting, scheduling, UI, incident management, lineage, or catalog — purely a test library; operations must be bolted on with an orchestrator or observability tool
- Maintenance risk — the original calogica repo is unmaintained since December 2024; continuity depends on the Metaplane (Datadog) fork
- Authoring is YAML-plus-SQL only with a dependency on dbt-date; complex assertions get verbose and there is no GUI for non-engineers
What dbt-expectations actually is.
What dbt-expectations is
dbt-expectations is a dbt package — a library, not a platform. It ports the assertion style popularised by the standalone Great Expectations framework into native dbt generic tests: 50-plus pre-built checks, declared in dbt YAML, that compile to SQL and run inside dbt test or dbt build against your own warehouse. The library spans row-count and volume checks, freshness windows, schema-shape assertions, value ranges and sets, regex and LIKE pattern matching, and distributional bounds (mean, median, standard deviation, quantiles, and N-standard-deviation envelopes).
What it is not: there is no UI, no scheduler, no alerting, no learned baseline, and no lineage. A test passes or fails, and that result flows through dbt’s normal machinery — severity levels, CI exit codes, and run_results.json artifacts.
Where it fits
It extends dbt’s four built-in tests for teams that want richer assertions without leaving the dbt project — a lighter, code-only alternative to soda or the full Great Expectations framework. Against elementary it adds no anomaly detection or reporting UI; against bigeye, monte-carlo, or anomalo it has no ML monitoring, lineage, or incident management. In practice it pairs with those tools rather than competing: several observability vendors document running dbt-expectations as the in-warehouse assertion layer beneath their platform.
On maintainership
The original package, by Calogica, was marked “no longer actively supported” in December 2024. Active development continues on a fork by Metaplane, which republished the canonical dbt Package Hub listing under its own namespace and keeps it current and dbt Fusion-compatible. Metaplane was acquired by Datadog in April 2025, so the practical maintainership chain today is Calogica (dormant) → Metaplane fork → a Datadog company. The licence never changed: it is Apache-2.0 and free.
How to evaluate it
Install the metaplane/dbt_expectations package, pick three or four checks your built-in dbt tests can’t express — a distributional bound on a key metric, a regex on an identifier column, a schema-shape assertion on a contract-like table — and wire them into the same CI that already runs dbt build. The evaluation question is narrow: does the assertion library cover the invariants you care about, and are you comfortable getting only pass/fail with no alerting or baselines on top?
All capabilities by cluster.
Quality & testing
Primary · strength 3/3Where it plugs in.
Native warehouse support
The honest pricing breakdown.
Free tier Entirely free. An Apache-2.0 dbt package installed from the dbt Package Hub; no paid tier, no SaaS, no usage metering. The only cost is your own warehouse compute when the generated test SQL runs.
What it doesn't do.
Uses machine learning models trained on historical data to detect values, volumes, or distributions outside expected bounds — without requiring the user to write explicit assertions. Reduces the "I didn't know to test for that" class of incident. Trade-off: requires a training window (typically two to four weeks), can produce false positives on seasonal data, and doesn't replace assertions for business-rule validation.
Column-Level Lineage →Traces data flow at the individual column granularity rather than just between tables. Critical for impact analysis when a column changes, for PII tracking, and for regulatory compliance in financial or healthcare contexts. Column-level lineage is computationally expensive and not all tools that claim "lineage" actually provide it — many stop at table level.
Data Contracts →Explicit, versioned agreements between data producers and consumers specifying schema, semantics, SLAs, and breaking-change policy. Enforced in CI for producers and at consumption time for consumers. Distinct from schema validation alone — a contract captures intent, not just structure. Implementations vary wildly; many tools claiming "data contracts" offer only schema checks.
Drill into one capability.
Other key features
If not dbt-expectations, then what?
Common alternatives
Quick answers.
- Is dbt-expectations open source?
- Yes. dbt-expectations is open source under the Apache-2.0 license, and can be self-hosted at no license cost. A paid managed tier is also offered.
- How much does dbt-expectations cost?
- dbt-expectations publishes pricing, starting around $0 custom. A free tier is available: Entirely free. An Apache-2.0 dbt package installed from the dbt Package Hub; no paid tier, no SaaS, no usage metering. The only cost is your own warehouse compute when the generated test SQL runs.
- How is dbt-expectations deployed?
- dbt-expectations is self-hosted — you run it in your own infrastructure.
- Does dbt-expectations work with dbt and my warehouse?
- It has a native dbt integration. dbt-expectations supports postgres, snowflake, bigquery, duckdb, trino, plus 1 more.
More quality & testing tools
Provenance.
Last verified 2026·05·30 against vendor documentation and, where possible, hands-on trial. Spot something off? Send a correction →