Precomputed permissions are authorization results that a system calculates ahead of time from its relationship graph and keeps continuously updated as data changes. Instead of walking every group, team, folder, and organization at the moment a request arrives, the application retrieves an answer that is already prepared. Think of it as materialized views, but for permissions.
Most authorization systems compute every decision on demand. That model works well until the relationship graph gets deep or wide, request volume climbs into the millions, or an AI agent needs to filter millions of documents in a single task. This guide explains why request-time authorization hits a ceiling, how precomputation removes it, how precomputed permissions stay correct, and when the approach is the right fit.
Why authorization gets expensive at scale
Authorization is relatively simple when an application has a small number of users, resources, and relationships. At enterprise scale, it isn't. In a relationship-based access control (ReBAC) system, a single decision can depend on relationships across users, groups, teams, roles, organizations, resources, and hierarchies. As those relationships grow, the computation required to answer certain permission questions grows with them.
Two shapes of graph cause most of the cost:
- Deep graphs. Access to a document might flow through a folder, a project, a department, and a parent organization. Groups can nest 20 levels deep, and each level is another lookup.
- Wide graphs. A single group can hold 200,000 members, and a single user can reach millions of resources. Questions like "which documents can this user see?" have to enumerate a very large answer.
AI compounds the problem. An AI agent may need to search millions of documents. A retrieval-augmented generation (RAG) pipeline may need to evaluate permissions across enormous datasets. An enterprise application may have thousands of users accessing millions of resources through complex organizational relationships. Authorization systems aren't making one decision. They're making millions or billions of them, and at that scale even small amounts of authorization latency become a constraint on the entire system.
Request-time evaluation vs. precomputed permissions
Traditionally, authorization decisions are computed when an application asks for them. A CheckPermission call walks the relationship graph one lookup per hop until it finds a path from the subject to the resource, or proves there isn't one.
SpiceDB's request-time evaluation, combined with its caching and request deduplication, handles most workloads well. Precomputation targets a narrower set of questions: the ones whose answers depend on very deep or very wide paths through the graph, where the same expensive work would otherwise repeat on many requests.
Precomputation changes the model. The system computes the results of resource-intensive permission queries before anyone asks and keeps those results continuously updated. When the application needs an answer, it retrieves the precomputed result instead of reconstructing the answer from scratch. Authorization can then handle much higher request volumes, because individual requests no longer carry the full computational cost of the underlying relationship graph.
The comparison to relational databases is direct. A materialized view stores the result of an expensive query so reads don't re-run the joins. A precomputed permissions store does the same for the transitive relationships behind your permission model.
Why caching isn't enough
Caching is effective for most workloads. SpiceDB caches subproblems during graph traversal, and Google's Zanzibar uses distributed caching across thousands of servers. For the most expensive queries, though, caching has structural limits:
- New questions start uncached. A cache only holds answers that were already computed, so a new user, resource, or query has to be evaluated first.
- Changes invalidate entries. Relationships change constantly in collaborative and AI systems, so cache entries are continually invalidated.
- Tail latency doesn't move. Caching can only help so much and has no bearing on p99 latency. The slowest requests are the cache misses on the deepest or widest paths, and those are exactly the ones that hurt.
A precomputed permissions store is not a cache. It computes answers before they're requested and keeps them current as data changes, so expensive questions are answered from prepared results whether or not anyone has asked them before.
How precomputed permissions stay correct
The hard part of precomputation is correctness. In a ReBAC system, permissions are derived from the relationship graph rather than stored as explicit access lists. A single relationship write, such as adding a user to a nested group, can change permissions across large portions of the graph. A precomputed store that lags behind those changes would grant access that was revoked or deny access that was granted.
AuthZed Materialize addresses this in two ways:
- Snapshots. It periodically recomputes its view from a snapshot of the relationship graph.
- A live change stream. Between snapshots, it consumes a live stream of relationship changes, such as the events SpiceDB emits through the Watch API, and incorporates those changes into the materialized view.
It also recalculates affected permissions when a new schema is written. This combination delivers the performance advantages of precomputation while preserving the correctness and consistency required for production authorization.
The Leopard index: precomputation in Google Zanzibar
Precomputed permissions are not a new idea. Google's Zanzibar paper describes a specialized indexing system called Leopard, built to handle deeply nested group memberships efficiently. Rather than walking every level of a group hierarchy on each request, Leopard maintains a precomputed index of group membership that Zanzibar consults during evaluation.
AuthZed Materialize takes inspiration from the Leopard index component described in the Zanzibar paper and brings the same pattern to SpiceDB as a managed service.
Workloads that benefit from precomputed permissions
Permission-aware lists and search
Showing users only what they're allowed to see is one of the hardest authorization problems at scale. Teams usually face three options:
- Check permissions for each result. This works for small result sets, but the total cost grows with every result you need to check.
- Denormalize permissions into your search index. Now you're maintaining two sources of truth, and permission changes require re-indexing.
- Use precomputed permissions. Accelerated Queries in AuthZed Materialize speed up
LookupResourcesandLookupSubjects, especially when there is a large number of resources. The hard work happens ahead of time, not per query, and precomputed sets update automatically when permissions change.
This pattern applies to permission-aware search, filtered dashboards, authorized reporting, and scoped list views. It matters most where the volume of secured resources reaches into the millions per user or tenant, as in legal tech, AI and data platforms, and large enterprise SaaS tenants.
RAG pipelines and AI agents
AI responses that leak unauthorized data are a security risk. In a RAG pipeline, checking permissions for every document during retrieval creates a bottleneck, and even at thousands of documents authorization performance can become the limiting factor in your pipeline. At the same time, revocations that take minutes or hours to propagate mean unauthorized data has already been exposed.
Precomputed permissions resolve that tension. Queries across millions of documents don't add authorization latency, and the live change stream keeps results current. Agents and RAG systems can operate across larger datasets and more complex permission structures without requiring authorization to be simplified or bypassed. For more on this pattern, see MCP authorization patterns and five common agent authorization mistakes.
Complex enterprise permission models
Large organizations often simplify their permission model to make it fast: flattening group hierarchies, limiting nesting, or replacing fine-grained sharing with coarse roles. Precomputation removes that pressure. Organizations can maintain sophisticated relationship-based authorization models without compromising in their design as users, resources, and relationships grow.
Precomputed permissions in SpiceDB with AuthZed Materialize
AuthZed Materialize is a service that runs alongside SpiceDB and precomputes the permissions you configure it to watch. By precomputing selected transitive relationships in SpiceDB, AuthZed Materialize delivers consistent performance for the authorization logic keeping large scale AI and Enterprise workloads secure.
How it fits into a SpiceDB deployment:
- You choose what to precompute. Much like defining a materialized view, you configure Materialize with a list of permissions to precompute. It produces permission sets, which capture which subjects are members of a permission and which sets are nested inside other sets.
- SpiceDB routes the expensive work. SpiceDB dispatches selected checks to Materialize, which answers from a precomputed view.
- Your application code doesn't change. Accelerated Queries use Materialize's precomputed permissions store to answer the SpiceDB queries your application already makes. They speed up
CheckPermissionandCheckBulkPermissions, along withLookupResourcesandLookupSubjects. - There's no new system to operate. As a fully supported, managed service, Materialize provides the infrastructure required to scale authorization without requiring teams to operate another distributed system themselves.
Materialize has supported production workloads with billions of relationships for select customers since 2024. It is generally available for AuthZed Dedicated, and existing AuthZed Dedicated customers can enable Materialize against their current commitment. Read the general availability announcement or the Materialize documentation for details.
Choosing what to precompute
Precomputation doesn't replace request-time evaluation. Many deployments use both: request-time evaluation for most permissions and precomputation for the few that are expensive to compute on demand.
Check the model constraints before you configure a permission for Materialize. Caveats, wildcard subject types, and .all intersections can exist in your schema but cannot be on the path of a configured Materialize permission. Expiring relationships aren't supported.
FAQ
What are precomputed permissions?
Precomputed permissions are authorization results that a system calculates ahead of time from its relationship graph and keeps continuously updated. When an application asks whether a user can view a document, or which documents a user can view, the system returns the precomputed result instead of traversing the graph at request time. The idea mirrors a materialized view in a relational database.
Is a precomputed permissions store the same as a cache?
No. A cache stores answers that were already computed on demand, so a new question has to be evaluated before it can be served from the cache, and entries are invalidated as relationships change. Caching can only help so much and has no bearing on p99 latency. A precomputed permissions store computes the results of resource-intensive permission queries before they are requested and keeps those results continuously updated.
How do precomputed permissions stay consistent when relationships change?
AuthZed Materialize periodically recomputes its view from a snapshot and consumes a live stream of relationship changes between snapshots. As relationships change, those changes are incorporated into the materialized view. This delivers the performance advantages of precomputation while preserving the correctness and consistency required for production authorization.
What is the Leopard index in Google Zanzibar?
Leopard is a specialized indexing system described in Google's Zanzibar paper. It handles deeply nested group memberships efficiently by precomputing them, so Zanzibar doesn't walk every level of a group hierarchy on each request. AuthZed Materialize takes inspiration from the Leopard index component described in the Zanzibar paper.
Do I need to change my application to use AuthZed Materialize?
No. Accelerated Queries use Materialize's precomputed permissions store to answer the SpiceDB queries your application already makes, including CheckPermission, CheckBulkPermissions, LookupResources, and LookupSubjects, without changing how you call SpiceDB.
Where is AuthZed Materialize available?
AuthZed Materialize is generally available for AuthZed Dedicated. Existing AuthZed Dedicated customers can enable Materialize against their current commitment. Contact AuthZed to learn more.