---
title: "Policy-first or relationship-graph-first authorization"
description: "Zanzibar is Google's internal authorization system, documented in a 2019 USENIX paper, which inspired open source systems including OpenFGA and SpiceDB. Cerbos PDP is a policy engine; the broader Cerbos platform also includes Cerbos Hub, Cerbos Synapse, and enforcement integrations."
competitor: "Zanzibar"
canonical: "https://www.cerbos.dev/cerbos-vs-zanzibar"
source: "https://www.cerbos.dev/cerbos-vs-zanzibar"
---

# Policy-first or relationship-graph-first authorization

Zanzibar is Google's internal authorization system, documented in a 2019 USENIX paper, which inspired open source systems including OpenFGA and SpiceDB. Cerbos PDP is a policy engine; the broader Cerbos platform also includes Cerbos Hub, Cerbos Synapse, and enforcement integrations.

## Verdict

**Choose Cerbos when**

- The default should combine an independently deployable open source PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment around contextual policy.
- Relationship facts already live in application systems and can be supplied for each decision.
- A stateless, locally deployed PDP is preferable to operating a separate relationship database.

**Consider Zanzibar when**

- The authorization domain is a large, dynamic graph with recursive inheritance or delegated sharing.
- Both principal-to-resource and resource-to-principal queries must be native operations.
- The system needs Zanzibar-style consistency controls across stored authorization relationships.

## Rules over attributes, or a graph of tuples

Google built Zanzibar to store and evaluate relationship-based ACLs globally, at a scale of trillions of ACLs and millions of authorization requests per second. It represents relations as tuples and evaluates relationship paths. Google does not sell Zanzibar as a standalone product; external adopters use Zanzibar-inspired systems such as OpenFGA and SpiceDB, self-hosted or through managed offerings.

The self-hosted Cerbos PDP evaluates CEL policy conditions at request time over principal, resource, request, and auxiliary data, without materializing a separate relationship graph. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, with no per-decision service call. The broader platform adds Cerbos Hub for policy lifecycle, signed distribution, fleet visibility, and audit; Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds decision-time context enrichment. Deep traversal and bidirectional indexes remain native graph-engine strengths.

**Zanzibar** — Zanzibar-style systems fit large, dynamic relationship graphs and commonly provide native traversal, bidirectional relationship queries, and consistency controls. Document sharing, nested folders, group inheritance, and delegated access are canonical use cases. Google proved its Zanzibar implementation at extreme scale; external implementations must be benchmarked separately.

**Cerbos** — Cerbos fits applications whose rules are contextual. Approval thresholds, record states, tenancy, regions, working hours, and clearance levels are expressed directly as policy conditions. Policies can be Git-managed as YAML or JSON with CEL expressions. The standalone Cerbos PDP stores no relationship graph, so it needs no relationship-data synchronization pipeline or graph-consistency token; policy distribution and input freshness remain separate concerns.

- **Where truth lives** — With the standalone Cerbos PDP, relationship attributes can remain in existing systems and be passed at decision time. Zanzibar-style deployments commonly persist relationships in a dedicated store; decide whether it is authoritative, synchronized from another source, or supplemented with request-time context.
- **Auditability** — When policies are Git-managed and decision logging is enabled, auditors can inspect policy files, change history, and structured decisions. Explaining a relationship-based decision may require reconstructing schema, tuple paths, request context, and a consistency snapshot; tooling varies by implementation.
- **Model mixing** — Express roles, attributes, and caller-supplied relationship facts in Cerbos policies. Relationship-first systems now support contextual conditions, while policy-first systems can consume graph-derived facts. Deep traversal and bidirectional indexes remain native graph-engine strengths.

## What the two models trade

The Zanzibar column describes the model as implemented by projects such as OpenFGA and SpiceDB. Specifics vary by implementation, so verify against the one you are evaluating.

| Requirement | Cerbos | Zanzibar model |
| --- | --- | --- |
| Contextual and attribute rules | NATIVE — Expresses amounts, statuses, regions, tenancy, and time directly as CEL conditions in policy. | SUPPORTED — Supports attributes through implementation-specific conditional relationships or caveats; some implementations also support contextual tuples. |
| Deep relationship traversal | PARTIAL — Evaluates relationship facts supplied as attributes. Commercial Cerbos Synapse can query an external graph through a proxy extension and inject a precomputed result; the Cerbos PDP does not traverse or materialize the graph. | NATIVE — Traverses stored relationship graphs natively, including nested and inherited access, within implementation-specific recursion and query limits. |
| Principal-to-resource listing | PARTIAL — Returns a condition AST through PlanResources for listing what a principal can access in the caller's datastore. It does not provide native resource-to-principal lookup. | NATIVE — Many implementations answer both principal-to-resource and resource-to-principal queries from the materialized graph, subject to documented limits. |
| Operational footprint | STATELESS PDP — The decision service requires no relationship database. Policy distribution and audit storage depend on the selected deployment. | STATEFUL — Persists relationship data in a backing store. Self-hosted deployments operate it; managed offerings do so for the customer. Synchronization is an application-design choice. |
| Policy as reviewable code | POLICY AS CODE — Expresses authorization rules in versionable, testable files; runtime identity, resource, and relationship data remain in external systems or requests. | SPLIT — Effective permissions derive from versioned schema plus stored relationships and any request-time context. |
| Freshness and consistency | BY DESIGN — The standalone Cerbos PDP maintains no relationship-data copy and evaluates the supplied context. Input freshness, Cerbos Synapse caching, and policy distribution have separate settings. | ENGINEERED — Implementations provide consistency controls to balance freshness and latency and prevent stale authorization after relationship changes; mechanisms vary. |
| Decision audit | BUILT IN, OPT-IN — When enabled, emits structured decision logs containing evaluation inputs, outputs, and policy metadata. | VERIFY — Varies by implementation. Effective access is distributed across tuple state, and decision audit is product dependent. |
| Adoption path | DIRECT — Deploys the Cerbos PDP as a binary or container and connects it to a supported policy store. | VIA IMPLEMENTATIONS — Arrives through OpenFGA, SpiceDB, or managed services, each with its own operational model and commercial terms. |

### Sources

- [Cerbos conditions](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html)
- [Cerbos derived roles](https://docs.cerbos.dev/cerbos/latest/tutorial/06_derived-roles.html)
- [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/)
- [Cerbos API](https://docs.cerbos.dev/cerbos/latest/api/index.html)
- [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/index.html)
- [Cerbos storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html)
- [Cerbos policy storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html)
- [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/policies/compile.html)
- [Cerbos audit logging](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html)
- [Cerbos binary installation](https://docs.cerbos.dev/cerbos/latest/installation/binary.html)

Reviewed against current Cerbos documentation, the Zanzibar paper, and implementation documentation on 24 July 2026. Verify specifics against the implementation you are evaluating.

## The source of truth determines the architecture

Cerbos consumes current domain facts; Zanzibar-style systems persist authorization relationships.

A Zanzibar-style implementation stores tuples such as user, relation, and object, then evaluates paths through a versioned authorization schema. This makes the relationship store directly queryable in both directions.

Cerbos policy evaluates the facts in a request. The application can load ownership, tenant membership, record state, and other attributes from its existing datastore before calling the Cerbos PDP.

Neither arrangement removes state management. A graph deployment must define tuple writes and consistency. A policy deployment must define input freshness and the boundary between application lookup, optional Cerbos Synapse enrichment, and Cerbos PDP evaluation.

## Contextual policy and graph traversal have different native shapes

Use the model that represents the difficult part of the domain directly.

Zanzibar-style systems are direct for nested folders, group inheritance, delegation, and reverse lookup. The graph answers how a principal is related to an object.

Cerbos is direct for rules such as a regional approver may release an invoice below a limit while the invoice is pending. Roles and CEL conditions evaluate in one policy decision.

The models can coexist. A graph can derive a relationship fact that Cerbos combines with current resource and request context. Commercial Cerbos Synapse can retrieve graph-derived context from customer-controlled infrastructure, but does not turn the Cerbos PDP into a graph engine.

## Consistency mechanisms apply to different data

Graph consistency protects relationship reads; policy deployments separate policy and input freshness.

Zanzibar introduced consistency mechanisms for relationship changes so stale authorization does not incorrectly preserve or remove access. External Zanzibar-inspired products expose implementation-specific controls.

The Cerbos PDP evaluates the request it receives against its loaded policy bundle. Relationship freshness is therefore owned by the caller or Cerbos Synapse data path, while policy distribution has its own lifecycle.

For restricted environments, the standalone open source Cerbos PDP can run without a cloud dependency. In supported JavaScript environments, Cerbos Hub's commercial ePDP can instead evaluate downloaded Cerbos Hub-managed bundles in-process through WebAssembly, with no per-decision service call. Cerbos Hub Enterprise can also run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure when enrichment is required.

## Keep graph traversal where it is native

A coexistence design can use a graph for inherited relationships and Cerbos for contextual policy.

| Zanzibar-style concept | Cerbos | Notes |
| --- | --- | --- |
| Authorization schema | Cerbos resource and principal policies | Move contextual allow and deny rules; keep recursive relation definitions in the graph. |
| Relationship tuple | Request attribute or graph-derived fact | Pass only the relationship result needed by the policy rather than copying the full graph. |
| Consistency token | Caller-defined freshness contract | The application or Cerbos Synapse data source determines whether the supplied fact is current enough. |
| Principal and resource listing | PlanResources for principal-to-resource filtering | Keep the graph for reverse lookup or traversals the application datastore cannot answer directly. |

### Combine a relationship result with current resource state

1. **1. Resolve relationship** — The graph service determines whether the principal is an inherited editor of the workspace.
2. **2. Load state** — The application loads the document classification, tenant, and lifecycle state from its source of truth.
3. **3. Evaluate policy** — Cerbos receives the graph result and current attributes, then evaluates the requested action against policy.
4. **4. Enforce** — The application applies the Cerbos decision and records the identifiers needed to trace both evaluations.

This split preserves native graph traversal while centralizing contextual rules. Define timeout, stale-data, and disagreement behavior before production use.

## Where Cerbos does not reproduce Zanzibar

Google's published Zanzibar architecture and external implementations solve graph workloads that a stateless policy engine does not.

| Capability | Cerbos approach | Guidance |
| --- | --- | --- |
| Materialized relationship graph | Cerbos PDP stores no application relationship tuples and does not traverse recursive relationship paths. | Use a Zanzibar-inspired implementation when the graph itself is the authorization system of record. |
| Bidirectional relationship queries | PlanResources filters resources for a principal through the application's datastore; Cerbos has no native resource-to-principal graph query. | Retain a graph engine or dedicated index when both query directions are required. |
| Zanzibar consistency semantics | The Cerbos PDP evaluates supplied context against loaded policy. It does not issue graph snapshot tokens or provide graph-specific consistency controls. | Specify freshness at each caller, Cerbos Synapse, policy-distribution, and graph boundary instead of assuming equivalent semantics. |

## ReBAC expressed in a policy engine

Ownership, membership, and tenancy can be expressed in Cerbos using caller-supplied attributes and derived roles. A document policy can grant editing to an owner, team, or collaborator list without a relationship store, provided those facts are included with the request.

Commercial Cerbos Synapse runs in customer-controlled infrastructure and can use a proxy extension to query an external graph store or system of record before Cerbos PDP evaluation. Cerbos Hub Enterprise can manage and distribute policy on-premise in restricted or air-gapped environments. A Zanzibar-style engine remains more direct when bidirectional relationship queries over large object sets are a core requirement.

Prototype representative rules in both models. Compare authoring, data flow, query patterns, consistency controls, deployment, and operating requirements. Cerbos fits when contextual policy, local evaluation, and source-controlled policy lifecycle dominate; a graph engine fits when deep traversal and bidirectional lookup dominate.

## Cerbos is the stronger default for contextual authorization

For application authorization centered on contextual rules, reviewable policy, controlled deployment, managed policy lifecycle, and optional enrichment, Cerbos is the stronger overall choice across Cerbos PDP, Cerbos Hub, and Cerbos Synapse. A Zanzibar-inspired implementation remains the stronger fit when a large relationship graph, bidirectional lookup, and graph-specific consistency are the core requirements. Benchmark the selected products with representative depth, fanout, list operations, and contextual rules.

## Questions you are probably asking

### Google proved Zanzibar at massive scale. Does that not settle it?

It proves Google's implementation for Google's workloads and scale. Assess whether your dominant requirements are deep traversal and bidirectional lookup, contextual policy evaluation, or a hybrid. Current implementations combine relationship and context features, but with different native strengths and operating models.

### Can Cerbos really express ReBAC?

Cerbos can evaluate ownership, membership, tenancy, and collaborator facts supplied as attributes. Commercial Cerbos Synapse can query external systems for graph-derived attributes before evaluation. Cerbos does not maintain a Zanzibar-style relationship graph or bidirectional reverse index, so a graph engine remains the more direct option for those workloads.

### Which Zanzibar implementation should we compare against?

OpenFGA and SpiceDB are prominent open source Zanzibar-inspired implementations, and each has a managed offering. They differ in APIs, consistency controls, query limits, backing stores, and commercial models. We publish a separate comparison with OpenFGA.

### What does the relationship model cost operationally?

A Zanzibar-style system is stateful and persists relationships in a backing store. In a self-hosted, duplicated-data design, the team operates the service and reconciles changes with the application database. Managed services and request-time context reduce parts of that burden, while using the relationship store as the source of truth changes it. The standalone Cerbos PDP removes relationship-store operation and reconciliation, at the price of assembling the required context for each request.

## The short version

**Cerbos strengths**

- Expresses contextual, attribute-driven rules directly
- Covers common relationship patterns when facts are supplied as request attributes
- Runs the Cerbos PDP statelessly, with no relationship graph to synchronize, back up, or keep consistent
- Keeps authorization policy logic in reviewable, testable files that can be managed in Git
- Provides opt-in decision logging and principal-to-resource query planning in the Apache 2.0 Cerbos PDP
- Commercial Cerbos Synapse can inject graph-derived relationship context before Cerbos PDP evaluation
- Cerbos Hub adds policy lifecycle management, signed distribution, fleet visibility, and audit
- Alex Olivier, Cerbos cofounder and CPO, is one of the current AuthZEN Working Group cochairs

**Weigh with Zanzibar**

- Google Zanzibar proved relationship evaluation at extreme scale; external implementations provide traversal and listing APIs with separate limits
- A natural model for products dominated by large, dynamic sharing graphs
- Implementation-specific consistency controls for stale-grant risk, latency, and throughput
- Open source implementations including OpenFGA and SpiceDB
- Managed services exist for teams that prefer not to operate the store
- Plan for a persistent relationship store; add synchronization when it duplicates data held elsewhere

Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you.