Technical decision brief
Cerbos vs Zanzibar
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.
The decision
Choose Cerbos when
- 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.
Choose 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.
At a glance
What the two models trade
The table describes documented mechanisms. It does not assign winner scores.
| Requirement | Cerbos | Zanzibar model |
|---|---|---|
| Contextual and attribute rules | Expresses amounts, statuses, regions, tenancy, and time directly as CEL conditions in policy. | Supports attributes through implementation-specific conditional relationships or caveats; some implementations also support contextual tuples. |
| Evidence for Contextual and attribute rules | ||
| Deep relationship traversal | 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. | Traverses stored relationship graphs natively, including nested and inherited access, within implementation-specific recursion and query limits. |
| Evidence for Deep relationship traversal | ||
| Principal-to-resource listing | 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. | Many implementations answer both principal-to-resource and resource-to-principal queries from the materialized graph, subject to documented limits. |
| Evidence for Principal-to-resource listing | EvidenceCerbos API (opens in a new tab) | |
| Operational footprint | The decision service requires no relationship database. Policy distribution and audit storage depend on the selected deployment. | 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. |
| Evidence for Operational footprint | ||
| Policy as reviewable code | Expresses authorization rules in versionable, testable files; runtime identity, resource, and relationship data remain in external systems or requests. | Effective permissions derive from versioned schema plus stored relationships and any request-time context. |
| Evidence for Policy as reviewable code | ||
| Freshness and consistency | 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. | Implementations provide consistency controls to balance freshness and latency and prevent stale authorization after relationship changes; mechanisms vary. |
| Evidence for Freshness and consistency | ||
| Decision audit | When enabled, emits structured decision logs containing evaluation inputs, outputs, and policy metadata. | Varies by implementation. Effective access is distributed across tuple state, and decision audit is product dependent. |
| Evidence for Decision audit | ||
| Adoption path | Deploys the Cerbos PDP as a binary or container and connects it to a supported policy store. | Arrives through OpenFGA, SpiceDB, or managed services, each with its own operational model and commercial terms. |
| Evidence for Adoption path | ||
Deep dive 1
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.
Deep dive 2
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.
Deep dive 3
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.
Implementation
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 | Migration or coexistence note |
|---|---|---|
| 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.
Deployment
Deployment control spans the Cerbos platform
The components can be adopted independently and placed according to runtime, governance, and network requirements.
Cerbos PDP
The Apache 2.0 decision engine runs as a shared service, sidecar, DaemonSet, or selected serverless topology.
Explore Cerbos PDPCerbos Hub
Commercial Cerbos Hub is hosted by default and is available to enterprise customers on-premise for restricted and air-gapped environments. The Cerbos ePDP evaluates Cerbos Hub-managed policy bundles in-process through WebAssembly in JavaScript environments.
Explore Cerbos HubCerbos Synapse
The commercial enrichment and integration layer runs in customer-controlled infrastructure in front of an embedded or external PDP.
Explore Cerbos SynapseCerbos capabilities
Follow the implementation details
These pages document the Cerbos mechanisms referenced throughout this comparison.
Research basis and disclosure
Claims were reviewed against public product documentation, official project material, and standards sources on 24 July 2026.
Reviewed against current Cerbos documentation, the Zanzibar paper, and implementation documentation on 24 July 2026. Verify specifics against the implementation you are evaluating.
Competitor documentation informed this comparison but is not linked from this page. Cerbos documentation and neutral standards or foundation sources were checked separately.
Alex Olivier, Cerbos cofounder and CPO, is one of the current OpenID Foundation AuthZEN Working Group cochairs. The Cerbos PDP API reference states that it partially implements the AuthZEN Authorization API.
Test the decision
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.