At a glance
| Supported data platforms | Any warehouse or database with a dbt adapter, such as Snowflake, Databricks, BigQuery, Redshift, PostgreSQL and Fabric |
| Anomaly detection | No, tests are explicit assertions |
| Freshness and volume monitoring | Source freshness checks are a separate dbt feature; volume checks only through tests you write |
| Schema checks | Through tests and model contracts you define; not automatic |
| Validation rules | Generic, custom generic and singular SQL tests; unit tests for model logic |
| Lineage and root cause | dbt's model DAG shows upstream models of a failing test |
| Alerting | Build failures and warnings in your orchestrator or the dbt platform; no built-in alert channels in dbt Core |
| Deployment | dbt Core CLI on Linux, macOS or Windows; or the managed dbt platform |
| Licensing | dbt Core Apache 2.0, free; dbt platform from free Developer to quote-based Enterprise |
If you transform data with dbt, its data tests are the first quality layer to use: they live next to the models in version control, run as SQL in your warehouse and can fail or warn a build. They only check what you write tests for, and only inside dbt-managed models and sources, so they complement rather than replace monitoring of freshness and volume across the warehouse.
Overview
dbt is a SQL transformation tool, and testing is part of it rather than a separate product. A data test is a query that returns failing rows: if it returns any, the test fails. Generic data tests are parameterised and attached to models, sources or columns in YAML; dbt ships four (unique, not_null, accepted_values and relationships), and you can write your own or install packages that add more. Singular data tests are one-off SQL files in the tests directory. Severity can be set to warn or error, with warn_if and error_if thresholds, and store_failures saves failing rows to an audit table.
Unit tests, added in dbt v1.8, check a model's SQL logic against small static inputs and expected outputs before the model is built, which suits regex, date maths, window functions and complex case expressions. dbt recommends running them in development and CI rather than production. Both kinds run with dbt test or dbt build, from dbt Core on your own machine or scheduler, or on the dbt platform.
Key features
- Four built-in generic tests: unique, not_null, accepted_values and relationships
- Custom generic tests written once as SQL macros and reused across models
- Singular tests: any SQL query that returns failing rows
- Unit tests (dbt v1.8 and later) on static inputs before a model is materialised
- Severity, warn_if and error_if thresholds to warn instead of failing a build
- store_failures to keep failing rows in an audit schema for investigation
- Tests versioned in Git with the models and run in CI with dbt build
Integrations and ecosystem
Pros and cons
Pros
- Free with open source dbt Core, and part of every dbt platform plan
- Tests are SQL, live in Git with the models and run in CI
- Can stop a bad build or just warn, per test
- Unit tests catch logic errors before data is built
Cons
- Only checks what someone has written a test for; no anomaly detection
- Covers dbt models, sources, seeds and snapshots, not the rest of the warehouse
- Unit tests support SQL models only, not materialized views, recursive SQL or introspective queries
- Large test suites add warehouse query cost on every run
Pricing
Data tests and unit tests are part of dbt itself, so they cost nothing to use with open source dbt Core (you still pay your warehouse for the queries they run). On the dbt platform (the managed service, previously dbt Cloud), the pricing page lists Developer free (1 developer seat, 1 project, 3,000 successful models built a month), Starter at USD 100 per user per month (up to 5 developer seats, 15,000 models built a month, overage billed, card billing monthly), and Enterprise and Enterprise+ by quote (100,000 models built a month, billed annually).
Pricing checked on the vendor's official page on 7 November 2026. Prices change; confirm before buying.
Who it is best for
Analytics engineering teams that build models with dbt and want assertions on keys, values and relationships in the same code review and CI process.
Typical use cases
- Asserting that primary keys in fact and dimension tables are unique and not null after each build
- Checking that every order references an existing customer with a relationships test
- Unit testing a revenue model's date and currency logic in CI before merging
- Saving failing rows with store_failures so analysts can investigate bad records
Who should look elsewhere
- Teams that want automatic monitoring of freshness, volume and anomalies across all tables: see Monte Carlo or Elementary, which builds on dbt.
- Pipelines that do not use dbt, such as Spark or pandas jobs: see Great Expectations or Deequ.
Verdict
dbt data tests are the cheapest and most natural quality checks for any team already using dbt, and unit tests close a long-standing gap for logic testing. They are deliberately explicit: nothing is checked unless you write a test, so most teams add source freshness checks and, as the estate grows, an observability tool on top.
Frequently asked questions
What is the difference between dbt data tests and unit tests?
Data tests run after a model is built and query the real data for failing rows. Unit tests, available from dbt v1.8, run before materialisation on small static inputs to check the SQL logic, and dbt recommends running them in development and CI only.
Are dbt tests free?
Yes, with dbt Core, which is open source under Apache 2.0; you only pay for the warehouse queries. The managed dbt platform has a free Developer plan, a Starter plan at USD 100 per user per month and quote-based Enterprise plans.
Why did tests become data_tests in YAML?
dbt renamed tests to data tests to distinguish them from unit tests. The data_tests key is current, the old tests key still works as an alias, but a resource cannot use both.
Who owns dbt now?
dbt Labs merged with Fivetran on 1 June 2026, and the company operates as Fivetran + dbt Labs. dbt Core remains open source.
Sources
- dbt docs: Add data tests to your DAG
- dbt docs: Unit tests
- dbt pricing
- dbt-core repository and licence (GitHub)
- Fivetran and dbt Labs complete merger (press release)
Checked November 2026.
Listed in: Data Quality & Observability.
How we research reviews and what star ratings mean: our editorial method.