Notifications
Clear all
Topic starter
10/06/2026 10:58 pm
TL;DR: Advisor-driven plan selection can cut permission check time from 11,175 µs to 182 µs in a wide fan-out scenario and reduce memory from 208 KB to 7.9 KB, according to Authzed’s SpiceDB query planner benchmarks, while dispatch choices remain a major tuning area. The result is a clearer picture of where ReBAC performance improves, and where planner decisions still need refinement.
NHIMG editorial — based on content published by Authzed: SpiceDB query planner benchmarks and dispatch optimizations
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.
Questions worth separating out
Q: How should teams optimize ReBAC permission checks in large graphs?
A: Start by identifying where the graph becomes broad, not just deep.
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.
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.
Practitioner guidance
- Map high-fanout authorization paths first Identify documents, groups, orgs, or folder structures that create wide arrows or repeated intermediate hops.
- Measure query latency by scenario shape Separate recursive chains, broad fan-out, and set-operation-heavy permissions in your testing.
- Tune dispatch against real cache economics Track whether dispatched subproblems are reused often enough to justify network cost.
What's in the full article
Authzed's full article covers the operational detail this post intentionally leaves for the source:
- The exact benchmark scenarios and schema definitions used to test recursive chains, fan-out, and set operations
- The full time and memory tables for algorithmic and datastore comparisons across in-memory, Postgres, and CockroachDB backends
- The specific planner optimizations and dispatch tradeoffs the team is currently tuning in SpiceDB
👉 Read Authzed's benchmarks on SpiceDB query planning and dispatch →
SpiceDB query planning and dispatch: what changes for IAM teams?
Explore further
12/06/2026 4:45 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SpiceDB query planning makes permission checks faster
