What causes Test Failure: relationships?

Rows were deleted from the parent model but the child model still references the old foreign key values. The child model receives data from a source that does not enforce foreign key constraints at the database level. A transformation bug introduced NULL or incorrect foreign key values in the child model. The parent and child models are loaded from different pipelines and a timing gap left orphaned rows after partial load. The `field:` argument in the test config points to the wrong column in the parent model

How do I fix Test Failure: relationships?

Query the failing rows directly: `SELECT * FROM WHERE NOT IN (SELECT FROM )`.. Determine whether the orphaned rows are a data problem (upstream pipeline issue) or a model logic problem (wrong join key).. If rows were legitimately deleted from the parent, decide whether to cascade deletes to the child or use a LEFT JOIN with NULL filtering.. Check the test config: verify `to:` points to the correct parent model and `field:` is the correct primary key column in that model.. For acceptable orphan rates, switch the test `severity` to `warn` and add a threshold: `config: severity: warn, warn_if: '>10'`.

High severitydata quality

Power BI Refresh Error:
Test Failure: relationships

What does this error mean?

dbt's built-in relationships test found rows in the child model whose foreign key values do not exist in the referenced parent model. This is a referential integrity failure — orphaned records exist in the data that violate the expected join relationship.

Common causes

1Rows were deleted from the parent model but the child model still references the old foreign key values
2The child model receives data from a source that does not enforce foreign key constraints at the database level
3A transformation bug introduced NULL or incorrect foreign key values in the child model
4The parent and child models are loaded from different pipelines and a timing gap left orphaned rows after partial load
5The `field:` argument in the test config points to the wrong column in the parent model

How to fix it

1Query the failing rows directly: `SELECT * FROM <child_model> WHERE <fk_column> NOT IN (SELECT <pk_column> FROM <parent_model>)`.
2Determine whether the orphaned rows are a data problem (upstream pipeline issue) or a model logic problem (wrong join key).
3If rows were legitimately deleted from the parent, decide whether to cascade deletes to the child or use a LEFT JOIN with NULL filtering.
4Check the test config: verify `to:` points to the correct parent model and `field:` is the correct primary key column in that model.
5For acceptable orphan rates, switch the test `severity` to `warn` and add a threshold: `config: severity: warn, warn_if: '>10'`.

Frequently asked questions

Does this test enforce foreign keys at the database level?

No — dbt's relationships test is a data quality assertion, not a database constraint. It reports violations but does not prevent orphaned rows from existing.

How do I find the exact orphaned rows?

Run `dbt test --select <test_name> --store-failures`. Dbt writes the failing rows to a table in the `dbt_test__audit` schema, which you can query directly.