Query planning for ReBAC: what data shape changes for IAM teams

TL;DR: SpiceDB’s experimental query planner reorders authorization checks using statistics about relationship shape, so it can reduce traversal work and lower latency in deep or wide ReBAC graphs, according to Authzed. The practical lesson is that authorization performance is increasingly a data-shape problem, not just an index or cache problem.

NHIMG editorial — based on content published by Authzed: SpiceDB query planning for ReBAC performance

Questions worth separating out

Q: How should teams reduce latency in large ReBAC authorization graphs?

A: Teams should reduce latency by identifying the highest-cost relationship paths, then simplifying schemas, reordering evaluation, or using planners that choose the cheaper traversal first.

Q: Why do some permission checks get much slower as relationship depth grows?

A: Permission checks slow down when the engine must explore many possible paths through a deep or wide relationship graph before it can prove access or denial.

Q: How do organizations know if authorization planning is actually working?

A: Organizations should look for lower traversal work, fewer expensive subgraph explorations, and reduced tail latency on permission checks that previously hit wide or deeply nested relationships.

Practitioner guidance

• Profile authorization hot paths Measure which permission checks consume the most traversal work, then map those paths back to relationship fan-out and nesting depth.
• Review schema shapes before tuning infrastructure Look at whether slow checks are caused by poor graph shape rather than raw datastore performance.
• Validate statistics against real tenant data Make sure any cost estimates used for evaluation ordering reflect the current distribution of relationships, not just synthetic benchmarks.

What's in the full article

Authzed's full article covers the operational detail this post intentionally leaves for the source:

• The exact shape of the sample document, group, and membership schema used to explain arrow and intersection planning
• The implementation logic behind de-duplicating requests, decomposing subproblems, and using consistent hashing for cache ownership
• The tree structure of query plans and how individual nodes can be reordered or rebalanced at runtime
• The planned next steps for adding more statistics sources and testing planner behaviour before default rollout

👉 Read Authzed's explanation of SpiceDB query planning for ReBAC performance →

Query planning for ReBAC: what data shape changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →