A recursive query repeatedly follows self-referencing relationships in a graph, such as users linking to friends who link to more friends. In GraphQL, recursion can become expensive very quickly if depth is not constrained. Without limits, the server may spend excessive CPU or memory resolving nested objects.
What makes recursive queries expensive
A recursive query walks a self-referencing structure repeatedly until it reaches a terminal condition. That makes it powerful for hierarchies and graph-like data, but also computationally heavy because each extra level can multiply the number of nodes or edges the system must evaluate.
The cost is not linear in the way many simple lookups are. As depth increases, the query may revisit large portions of the structure, expand many branches at once, or materialize intermediate results that consume memory before the final response is produced.
Where recursive queries are used
Recursive queries are common when data contains parent-child or peer-to-peer relationships that cannot be answered with a single join. Typical examples include organisational trees, category hierarchies, dependency graphs, social connections, and access-path exploration in graph databases or graph-like application data.
In relational systems, recursion is usually expressed with a common table expression or an equivalent iterative mechanism. In graph systems, the same idea appears as repeated traversal across linked vertices and edges. The implementation differs, but the conceptual risk is the same, each recursive step expands the search space.
Why recursion can create performance and availability pressure
Recursive queries become dangerous when the branching factor is high, the graph is dense, or the termination condition is weak. A query that looks harmless at shallow depth can suddenly fan out across thousands or millions of relationships, creating excessive CPU use, long lock times, large result sets, or memory pressure on the database engine.
That matters because the query pattern can be triggered accidentally by a legitimate application path just as easily as by a deliberate abuse case. If the system does not constrain depth, row count, execution time, or traversal scope, one request can monopolise shared database resources and degrade service for other users.
How to reason about recursive query safety
Safe use of recursion starts with understanding the data shape, not just the syntax. A query should have a clear stop condition, a bounded search depth, and a realistic expectation of how many rows each recursive step may add. In practice, the main question is whether the traversal remains predictable under worst-case data, not whether it works on a small sample.
It also helps to distinguish intended exploration from accidental overreach. A recursive query that is perfect for a narrow administrative lookup may be inappropriate for an unbounded user-facing endpoint. The same pattern can be acceptable in one context and risky in another, depending on exposure, concurrency, and the size of the underlying graph.
Risk and Threat Considerations
Recursive queries create a denial-of-service style risk when an attacker, or even a poorly bounded application call, forces the database to expand too much work from a single request. The danger is amplified in graph-heavy datasets, where traversal depth and branching can escalate very quickly.
Failure mechanism: The query expands relationships faster than the engine can efficiently prune them, leading to runaway execution, excessive memory use, or expensive intermediate result materialisation.
Impact: Response times can spike, shared database resources can be exhausted, and dependent services may fail or stall while the recursive workload is running.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Recursive-query abuse is a workload pattern that needs monitoring for abnormal resource consumption. |
| SC-5 — Denial of Service Protection | Unbounded recursion can exhaust database resources in a service-denial pattern. | |
| Recommendation — Monitor recursive query execution patterns and alert on abnormal depth, duration, or resource use. Apply DoS protections that limit recursive workload impact on shared database services. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | Recursive traversal can be abused to consume excessive CPU, memory, and execution time. |
| Recommendation — Cap traversal depth and execution cost to prevent recursive requests from monopolising resources. | ||
Practitioner Guidance
What to watch for: Treat recursion as a bounded traversal problem, not a convenience feature. If the data can contain cycles, very deep chains, or wide fan-out, the query design needs explicit limits and careful testing against worst-case structure, not just normal records.
Practitioner takeaway: Recursive queries are safe only when their cost is predictable. If you cannot estimate how work grows as depth increases, the query is a performance and availability risk even when it is functionally correct.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org