---
title: "dbt models with too many direct dependents | Metacenta"
description: "A dbt model that many others read directly is a single point of failure. The threshold we flag at, and how to protect the model instead of splitting it."
url: "https://metacenta.com/rules/fan-out-hotspot"
updated: "2026-10-14"
tokens: 685
---

Lineage integrity · rule fan-out-hotspot

# dbt models with too many direct dependents

A Metacenta review checks this under the rule **No model is a single point of failure**. Everything below applies whether or not you ever commission one.

## What this rule checks

This rule flags any dbt model that more than 15 other models read directly through `ref()`. Only direct dependents count. Exposures, tests and indirect descendants don't, and sources aren't judged here.

## Why it matters

One defect in the model reaches every dependent at once. Any change to its columns is effectively a breaking change for all of them.

## How to fix it

**Treat the high-fan-out models as contracted interfaces.** Treat the model as a contracted interface. Enforce a contract on its columns, and assert its grain with `unique` and `not_null` tests before anything else.

Before:

```yaml
models:
  - name: dim_customers
    columns:
      - name: customer_id
```

After:

```yaml
models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: int
        data_tests:
          - unique
          - not_null
```

## When it is fine to leave

A shared dimension such as `dim_customers`, or a calendar table, is meant to be read widely. The finding is informational: it names where a defect would spread furthest. Keep the fan-out, and protect the model with a contract and tests.

## What we need to check it

`manifest.json` alone. Each finding states how many models depend on it directly. The threshold is a review setting, 15 by default.

## Published rules it corresponds to

**[dbt_project_evaluator](https://dbt-labs.github.io/dbt-project-evaluator/)**, rule `fct_model_fanout`. Ours checks the same concern, tested differently. dbt Labs' rule counts direct *leaf* children over a default of 3; this one counts direct dependents of any kind, so the two flag overlapping but different sets.

This means our check corresponds to their rule. It does not mean the publisher reviewed or endorses it.

[Ask about a review](https://metacenta.com/enquire?src=rule-fan-out-hotspot&via=md)

## Related pages

- [dbt dependency cycles in the model DAG](https://metacenta.com/rules/dependency-cycle)
- [dbt models with a hardcoded table name](https://metacenta.com/rules/hardcoded-table-reference)
- [dbt exposures: what they are and how to declare them](https://metacenta.com/rules/model-possibly-unused)
- [Deep dbt lineage: long chains of models](https://metacenta.com/rules/deep-lineage)
- [A sample review, as a client reads it](https://metacenta.com/sample)
- [All published rules](https://metacenta.com/rules)
- [How a review is assessed](https://metacenta.com/standard)
