Circular dependencies between SQL files

For SQL projects without dbt, this rule flags relations that depend on themselves through other relations: A is built from B, and B from A. We rebuild the lineage from what each file writes and reads. A file that reads the table it writes, such as an incremental load, does not count as a cycle.

No build order can satisfy a cycle. Each run reads the previous run's output, so one bad load keeps recurring.

Break the cycles in the SQL lineage. Break the cycle. Usually one side can read the upstream data both are built from. Where carrying state between runs is the point, keep that state in its own history table and document it in each file.

Before:

-- customers/query.sql
create or replace table analytics.customers as
select customer_id, lifetime_value
from analytics.order_totals;

-- order_totals/query.sql
create or replace table analytics.order_totals as
select o.customer_id, sum(o.amount) as lifetime_value
from raw.shop_orders as o
join analytics.customers as c using (customer_id)
group by o.customer_id;

After:

-- order_totals/query.sql
create or replace table analytics.order_totals as
select o.customer_id, sum(o.amount) as lifetime_value
from raw.shop_orders as o
join raw.shop_customers as c using (customer_id)
group by o.customer_id;

A loop that carries state between runs on purpose, split across two files, can be deliberate. It still has no clean build order, so document it in both files. Tell us, and the finding comes out of your report.

The .sql files, read from your repository with read-only access or uploaded. We infer lineage from statements and folder layout without running the SQL, so the finding is medium confidence. Assertion files such as checks.sql do not count as writers.