SpiceDB query planning makes permission checks faster

At a glance

What this is: Authzed’s benchmark post shows that query planning and dispatch can materially improve SpiceDB permission-check performance by choosing better evaluation paths.

Why it matters: IAM and platform teams should care because ReBAC performance directly affects access-check latency, cache efficiency, and the practicality of graph-shaped authorization at scale.

By the numbers:

• In the same DoubleWideArrow scenario, QP Plain used 208 KB of memory while QP Advised used 7.9 KB.
• In the Postgres datastore benchmark, QP Local handled WideArrow in 0.50 ms versus 1.33 ms for current Dispatch.

👉 Read Authzed's benchmarks on SpiceDB query planning and dispatch

Context

SpiceDB permission checks become slower when the query engine evaluates the wrong side of a graph or walks too many subproblems. In a ReBAC system, that means the cost of authorization is no longer just a schema question, but a routing question inside the permission graph.

This matters to identity teams because authorization latency shapes user experience, cache behaviour, and cluster cost. When relationships fan out across groups, orgs, folders, or nested resources, the difference between a local shortcut and a poor plan can be the difference between predictable access control and expensive graph traversal.

The article is really about how a permission engine should decide where to do work, not simply whether it can do the work. That makes it relevant to anyone operating graph-based authorization as part of a wider IAM or workload-identity programme.

Key questions

Q: How should teams optimize ReBAC permission checks in large graphs?

A: Start by identifying where the graph becomes broad, not just deep. The best gains usually come from reducing fan-out, preserving short-circuit opportunities, and letting the engine evaluate the most selective branch first. Teams should benchmark realistic relationship shapes, because access models that look elegant in schema form can be expensive at runtime.

Q: Why do some authorization checks get slower as graphs grow?

A: They get slower when the engine must explore many intermediate relations before it can answer the request. Large fan-out, nested arrows, and poorly ordered branches multiply work even when the final answer is simple. The key signal is not graph size alone, but how much unnecessary traversal the model forces on each check.

Q: How do you know if dispatch is helping authorization performance?

A: Dispatch is helping when repeated subproblems are reused often enough to offset network and serialization cost. If the same work is not being cached and replayed, dispatch can become slower than local evaluation. The right metric is end-to-end latency plus reuse rate, not cache size by itself.

Q: What should IAM teams do when permission logic depends on many graph hops?

A: They should treat the hop count as an operational design variable, not just a schema detail. More hops increase the chance of wasted traversal, especially when the request could have been answered by a narrower branch. Benchmarking each hop pattern is the only reliable way to see where the real cost sits.

Technical breakdown

Query planning in ReBAC authorization

ReBAC systems evaluate access by traversing relationships in a permission graph. A query planner turns that traversal into a route selection problem, using hints from static assumptions or observed cardinality to decide which branch to evaluate first. In SpiceDB, that matters because each hop can become a separate subproblem with different cache and network costs. The planner is therefore not just a performance layer. It is part of the authorization execution model, especially when the graph contains recursive parent chains or highly shared groups.

Practical implication: model your authorization paths so the planner can exploit small, selective branches instead of forcing broad traversal.

Arrow reversal, branch ordering, and short-circuiting

Arrow reversal changes the direction of evaluation so the engine enumerates the smaller side of an intersection first. Branch ordering applies the same logic to unions and intersections, putting the most likely grant or most selective miss in front so the engine can short-circuit sooner. Arrow rotation rewrites nested arrows into a cheaper equivalent shape, which can reduce work even when the permission meaning stays the same. These are classic cost-based optimizations, but applied to authorization graphs rather than relational tables.

Practical implication: use schema and relationship patterns that preserve selective evaluation opportunities instead of hiding them behind wide fan-out.

Dispatch versus local evaluation in clustered authorization

Dispatch breaks a permission check into subproblems that another node can evaluate and cache, trading network overhead for potential reuse. That is useful when a cluster can amortize repeated subproblem results, but it becomes expensive when the engine over-dispatches. The benchmark data shows that current dispatch is still being tuned, especially in datastore-backed environments where gRPC and storage latency can outweigh the cache win. The operational question is not whether dispatch exists, but when moving work off-node is cheaper than keeping it local.

Practical implication: measure dispatch frequency against cache hit rate and latency before assuming cluster distribution will improve authorization.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Query planning is becoming a first-class authorization control, not a backend detail. In graph-based IAM, the difference between a fast permission check and an expensive one is often the difference between a usable model and an operational bottleneck. Cost-based planning changes how ReBAC behaves at scale because it decides which graph edges deserve attention first. Practitioners should treat authorization execution as part of identity architecture, not just application plumbing.

Wide fan-out is the real cost centre in relationship-based access. The benchmark scenarios show that broad sharing patterns, not simple recursion alone, create the most waste when the engine starts from the wrong side. That is a schema design problem as much as a query problem, because a permission graph with large intermediate sets forces avoidable work. The practical conclusion is that access model shape directly affects runtime efficiency.

Dispatch only helps when the cacheable subproblem is worth the network hop. The article’s early numbers show that distributed evaluation can help, but also that it can become slower than local execution when the planner over-splits work. This is the classic runtime governance problem for distributed authorization: where to keep work local, where to reuse it, and where to stop chasing cache wins. Teams should think in terms of subproblem economics, not just cluster scale.

Arrow reversal and branch reordering are the authorization equivalent of join-order optimization. The planner is effectively choosing the least expensive path through a graph, with short-circuiting as the main performance lever. That matters because ReBAC systems inherit database-like cost tradeoffs but operate inside access decisions that users experience directly. Practitioners should assume that poor graph shape will surface as latency, not just inefficiency.

ReBAC performance exposes the hidden governance cost of over-generalised sharing. The better the graph planner becomes, the more obvious it becomes when the underlying model creates unnecessary breadth. That is a useful discipline shift for identity teams because it pushes them to ask whether a resource should be shared through a broad org path or through narrower, more selective relations. The field should read these benchmarks as a reminder that authorization model design and runtime behaviour are inseparable.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That fragmentation and behaviour gap together show why identity governance must stay aligned with how systems actually route and reuse access, not how teams hope they do.

What this signals

Query execution should be treated as an identity performance control. When authorization checks sit on the critical path, planner quality affects user-facing reliability in the same way that policy design affects access correctness. Teams operating ReBAC at scale should watch for graphs whose shape forces broad traversal, because those models will generate avoidable latency even when policy logic is sound.

The practical signal is that schema shape and cluster architecture now need to be reviewed together. If dispatch is introduced before the planner has enough cost knowledge, the system can shift work around without actually reducing it. That is why benchmark-driven governance matters in authorization engineering, especially for environments with deep nesting or wide sharing.

Identity blast radius: the more broadly a resource is shared, the more expensive it becomes to prove or disprove access efficiently. That means access model design is not just about correctness but also about containment of computational cost. Teams should align performance testing with the same relationship patterns that define their real authorization risk.

For practitioners

• Map high-fanout authorization paths first Identify documents, groups, orgs, or folder structures that create wide arrows or repeated intermediate hops. Those are the paths most likely to benefit from planner-aware schema redesign or targeted caching.
• Measure query latency by scenario shape Separate recursive chains, broad fan-out, and set-operation-heavy permissions in your testing. The performance profile of each shape is different, and aggregate averages hide the paths that hurt users most.
• Tune dispatch against real cache economics Track whether dispatched subproblems are reused often enough to justify network cost. If a subproblem is rarely reused, keeping it local may be faster than sending it across the cluster.
• Review schema shapes that obscure selectivity Look for permission expressions that hide a small, selective branch behind a large union or nested arrow. Those expressions often need refactoring so the planner can short-circuit earlier.

Key takeaways

• Query planner quality now directly affects whether graph-based authorization stays practical at scale.
• The biggest performance gains come from reducing fan-out, reordering branches, and avoiding unnecessary dispatch.
• Identity teams should benchmark access models by graph shape, because runtime cost often follows the structure of the permission graph.

Key terms

• ReBAC: Relationship-based access control grants access by evaluating paths through relationships between subjects, resources, and intermediary objects. It is useful when permissions depend on how things are connected rather than on simple roles alone, but its runtime cost depends heavily on graph shape and traversal strategy.
• Query planner: A query planner is the component that decides which order and direction to evaluate parts of an authorization request. In graph-based access control, it turns reachability into a cost-based routing problem, choosing paths that can reduce fan-out, short-circuit sooner, and limit unnecessary work.
• Dispatch: Dispatch is the act of sending a subproblem to another node or service for evaluation instead of resolving everything locally. In clustered authorization systems, it can improve caching and throughput, but only when the reused work outweighs the overhead of network transfer and coordination.
• Fan-out: Fan-out is the number of downstream entities reached from a single relationship step in a graph. High fan-out increases the number of candidate paths an authorization engine must evaluate, which can raise latency and memory use even when the final permission result is simple.

Deepen your knowledge

Query planning, ReBAC performance, and relationship graph design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or operating graph-based authorization at scale, it is worth exploring.

This post draws on content published by Authzed: SpiceDB query planner benchmarks and dispatch optimizations. Read the original.