## TL;DR

The `not_null` test found null values in `orders.customer_id`. Re-run the test with `--store-failures` so dbt saves the offending rows to a table, query that table to see which rows are null, then fix the model logic or the upstream data that produced them.

## Error

```text
Database Error in test not_null_orders_customer_id
```

## Steps

1. Re-run just this test and store the failures: `dbt test --select not_null_orders_customer_id --store-failures`. Expected: the run completes and reports a failures table location.
2. Query the failures table in your warehouse (it lands in the test schema, named after the test). Expected: you see the actual rows where `customer_id` is null.
3. Check whether the nulls come from the source or from model logic: compare against the raw table and look for joins that drop the key. Expected: you identify the step that introduces the nulls.
4. Fix the cause: add a `coalesce`, filter bad rows, or repair the upstream source. Expected: the model logic no longer produces null keys.
5. Re-run `dbt test --select not_null_orders_customer_id`. Expected: the test passes with zero failing rows.

## When to use

- `dbt test` fails on a `not_null` generic test with a Database Error.
- You need to see the failing rows, not just the failure count.

## When not to use

- The test fails at parse time with an "Invalid test config" error (a YAML problem, not a data problem).
- The test name is misspelled in your `--select` (dbt reports no matching tests).

## Tool compatibility

- dbt Core 1.0 and later, all adapters. `--store-failures` needs a test schema your role can write to.

## Variant phrasings

### Database Error in test not_null_[model]_[column]

Same pattern for any column: the test found nulls, and the fix is in the data or the model.

### Failure in test not_null ... got 5 results, configured to fail if > 0

The long form of the same failure, with the failing row count included.

## Why it happens

`not_null` compiles to a query that selects rows where the column is null. Any nulls in the built model, whether from the source or introduced by a join or a case expression, fail the test.

## Edge cases

- Empty strings are not null; if your nulls are actually `''`, the not_null test passes and you need a separate check.
- Tests run against the model's target schema; make sure you rebuilt the model before re-testing.
- On BigQuery, the failures table lands in the test dataset configured in your profile.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2k2l_wR7i345QYUziTKSjQ