Well Tested vs. dbt Tests
dbt tests are the standard for data quality inside transformation pipelines. Well Tested checks what dbt cannot see: schema state in production and what changed since the last release.
| Dimension | Well Tested | dbt Tests |
|---|---|---|
| When it runs | At release time — before you ship | During pipeline run — when data transforms |
| What it checks | Schema state + data behavior in live production | Data quality inside transformation models |
| Schema changes | Tracks column adds, drops, type changes, and their downstream risk | Not designed for schema tracking |
| Historical patterns | Links schema changes to past incidents (recurrence risk) | No incident correlation |
| Release gate | Yes — structured approve/investigate/block decisions | No release decision surface |
| Downstream detection | Yes — checks if a change affects reporting, billing, or key tables | Tests within models, not cross-system impact |
| Setup required | Connects to Postgres, reads schema state automatically | Requires dbt project, models, and test definitions |
How they differ in practice
The timing difference
dbt tests run when your data transformation pipeline executes — validating that the data flowing through your models meets expectations. This is valuable. But it only tests data inside the transformation layer. It cannot see what happens to schema structure in the production database between one release and the next.
Well Tested runs at release time, before you merge. It reads the live production schema, detects what changed since the last release, and flags anything that could break downstream systems — billing columns, reporting tables, services that read a column you're about to drop.
Where they overlap
If your dbt project sources data from production tables, dbt tests can validate the data that lands in those source tables. But dbt tests cannot detect that a column was dropped in production last Tuesday — or that billing.invoice_items.due_date has caused billing incidents three times in the last 90 days and should be treated as a high-risk table.
Well Tested and dbt tests are complementary. dbt validates transformation logic; Well Tested validates release readiness.
What Well Tested catches that dbt cannot
- →Schema changes to production tables outside the dbt project
- →A column drop that will break a reporting query — before the release, not after
- →A table with a recurrence pattern: 'this table breaks every time someone touches it'
- →Cross-system impact: if this schema change reaches billing or analytics tables
- →Downstream schema dependencies that your dbt models didn't account for
Who is this comparison for
Use Well Tested if:
- • Your team ships releases that touch Postgres
- • You want to know what changed before customers feel it
- • You need a structured release decision (approve/block)
- • You want to know if a table has a history of breaking
Use dbt tests if:
- • You want data quality checks inside transformation models
- • You need to validate business logic (nulls, uniqueness, ranges)
- • You already have a dbt project and want to expand coverage
- • Pipeline-time validation is sufficient for your team
Your first 3 runs are free. A card is required before starting a paid-tier trial.