---
title: "A relationship graph or a policy engine"
description: "OpenFGA primarily evaluates whether relationships exist using a model and stored or contextual tuples. Cerbos PDP evaluates whether an action is allowed using policy and request-supplied attributes. The right choice depends on the shape of the authorization problem."
competitor: "OpenFGA"
canonical: "https://www.cerbos.dev/cerbos-vs-openfga"
source: "https://www.cerbos.dev/cerbos-vs-openfga"
---

# A relationship graph or a policy engine

OpenFGA primarily evaluates whether relationships exist using a model and stored or contextual tuples. Cerbos PDP evaluates whether an action is allowed using policy and request-supplied attributes. The right choice depends on the shape of the authorization problem.

## Verdict

**Choose Cerbos when**

- The default should combine an independently deployable open source service PDP, an optional commercial Cerbos Hub-managed WebAssembly ePDP, and commercial Cerbos Synapse enrichment around attribute-led authorization.
- Application relationship data should remain in existing systems rather than a second materialized tuple store.
- The decision service must run locally and independently from a managed authorization API.

**Consider OpenFGA when**

- Permissions form a deep relationship graph with nested groups, folders, sharing, or delegation.
- Native ListObjects and ListUsers operations are central to the application.
- A Zanzibar-style model is the intended source of truth for authorization relationships.

## Two models for fine-grained access

OpenFGA is an Apache 2.0 authorization system inspired by Google's Zanzibar, developed by Okta employees and now a CNCF Incubating project. Its primary model stores relationships as tuples and evaluates the resulting graph. Auth0 FGA is the managed service built on OpenFGA. Cerbos PDP evaluates each decision from attributes supplied at request time and does not require a duplicate relationship-tuple store; the caller or Cerbos Synapse still sources those attributes.

The Cerbos platform extends the self-hosted Cerbos service PDP with Cerbos Hub for policy authoring, testing, signed distribution, fleet visibility, audit, and an in-process WebAssembly Cerbos ePDP for JavaScript environments. Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds identity, resource, and relationship enrichment. Neither component turns Cerbos into a materialized graph engine. OpenFGA is more direct for graph traversal and native list operations; Cerbos makes attribute and context conditions the core policy model.

**OpenFGA** — Fits products whose permissions form a relationship graph. Nested folders, group inheritance, delegated access, and document sharing at large fanout are the Zanzibar model's home ground. OpenFGA provides native ListObjects and ListUsers APIs, model tests, IDE validation, a CLI, and a GitHub Action, and it is a CNCF Incubating project.

**Cerbos** — Fits systems where decisions turn on attributes and context. Policies express amount limits, record status, regions, and tenancy directly in YAML or JSON with CEL expressions. The Cerbos PDP does not persist application relationship data for evaluation, so it needs no second relationship store to reconcile. Policy and audit storage still depend on the configured backend.

- **The data sync question** — When relationship data is duplicated between an application and OpenFGA, it needs a synchronization pattern because no transaction spans both systems. OpenFGA can instead be authoritative for some authorization data or accept contextual tuples. Cerbos PDP does not persist application relationship data for decisions; it evaluates request-supplied attributes.
- **Attribute conditions** — Express amount, status, region, and time conditions as the core Cerbos policy model. OpenFGA supports CEL conditions and contextual tuples, with published request-size, tuple-count, and evaluation-cost limits.
- **What you operate** — The open source Cerbos PDP can run as a sidecar, DaemonSet, or central service. Cerbos Hub ePDP evaluates Cerbos Hub-managed bundles in-process through WebAssembly in JavaScript environments. OpenFGA can run as a service backed by PostgreSQL, MySQL, or SQLite, or as a library in a Go service. Auth0 FGA puts checks on an Auth0-managed API path.

## What the two models trade

Each row was reviewed against first-party documentation on 24 July 2026. The models have different native strengths and deployment tradeoffs.

| Requirement | Cerbos | OpenFGA / Auth0 FGA |
| --- | --- | --- |
| Attribute and context decisions | NATIVE — Evaluates CEL conditions over principal, resource, and request attributes as the core model. | BOUNDED — Supports conditions and contextual tuples as an extension to the relationship model, with documented limits on context size, evaluation cost, and per request tuples. |
| Relationship graph at scale | PARTIAL — Evaluates supplied relationships through attributes and derived roles. Commercial Cerbos Synapse can retrieve graph-derived context at request time. For reverse relationship queries across very large object sets, a materialized graph is generally more direct. | NATIVE — Purpose built for the sharing graph shape, with native traversal and reverse queries over stored tuples. |
| State and operations | STATELESS — The Cerbos PDP can run as a single binary without an application-data database. It has no relationship-tuple store to synchronize; policy and audit storage follow the selected backend. | STATEFUL — For persistent storage, supports PostgreSQL, MySQL, or SQLite and can be embedded in a Go service. Synchronization is required only when authorization data is duplicated elsewhere; Auth0 FGA is the managed option. |
| Decision path | LOCAL OR IN-PROCESS — The Cerbos service PDP can decide beside the workload as a sidecar or DaemonSet. Cerbos Hub ePDP evaluates in-process through WebAssembly in JavaScript environments without a per-decision service call. | DEPENDS — Standalone OpenFGA adds an API hop and persistent datastore access; embedding it as a Go library removes the separate service hop. Auth0 FGA checks use an Auth0-managed regional API. |
| Decision and audit logs | BUILT IN — When enabled, emits structured decision logs containing authorization requests, outcomes, and context, with configurable storage backends. | DEPENDS — Open source provides a tuple-change log rather than a decision-audit API. Auth0 FGA provides a Logging API across public endpoints with published seven-day retention. |
| Listing what a user can access | QUERY PLAN — Returns a filter through the Query Plan API to run against your own database, with ORM adapters. | NATIVE — Provides native ListObjects and ListUsers. Nonstreaming endpoints default to a configurable 1,000-result maximum; streamed ListObjects has no fixed cap but remains workload- and deadline-dependent. |
| Testing and CI | BUILT IN — Ships a first class test format and compile checks designed for authorization policies. | BUILT IN — Provides model tests, editor validation, CLI support, and CI integration. |
| Open source and pricing transparency | APACHE 2.0 — Publishes the Cerbos PDP under Apache 2.0 with public pricing and a free tier. Cerbos Hub and Cerbos Synapse are commercial add-ons. | MIXED — OpenFGA is Apache 2.0 and CNCF Incubating. Auth0 FGA publishes trial and Enterprise limits, but production requires an Enterprise contract and no public per-unit rate is shown. |

### Sources

- [Cerbos resource policies](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html)
- [Cerbos policy evaluation](https://docs.cerbos.dev/cerbos/latest/policies/evaluation.html)
- [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/)
- [Cerbos storage drivers](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html)
- [CNCF OpenFGA project](https://www.cncf.io/projects/openfga/)
- [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/index.html)
- [Cerbos Hub embedded PDP](https://docs.cerbos.dev/cerbos-hub/deployments-epdp-rules.html)
- [Cerbos audit logging](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html)
- [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html)
- [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/tutorial/04_testing-policies.html)
- [Cerbos pricing](https://www.cerbos.dev/pricing)

Reviewed against linked Cerbos and neutral foundation sources plus current first-party product documentation on 24 July 2026. Verify current capabilities before deciding.

## Policy evaluates facts; a graph derives them

The main difference is what each engine treats as its native input and state.

OpenFGA stores relationship tuples and evaluates paths defined by an authorization model. It is direct for questions such as whether a user belongs to a group that can view a document through an inherited folder relation.

Cerbos evaluates actions against policy using principal, resource, and request attributes supplied for that decision. Ownership, tenant membership, record state, region, and amount thresholds can be expressed together as CEL conditions.

Cerbos can consume a relationship result, but the Cerbos PDP does not become a graph database. OpenFGA can add conditions and contextual tuples, but its native abstraction remains the relationship graph.

## Relationship state changes the failure model

A tuple store creates native graph capabilities and a data-lifecycle obligation.

OpenFGA can be authoritative for authorization relationships. If the same relationship also exists in an application database, the system needs a synchronization and reconciliation design because no transaction spans both stores.

The Cerbos PDP stores no application relationship graph. The caller supplies current facts, or commercial Cerbos Synapse retrieves them at decision time from customer-controlled infrastructure.

The tradeoff is explicit. OpenFGA provides graph traversal and reverse lookup. Cerbos avoids a duplicated tuple store but depends on the caller or Cerbos Synapse to provide sufficiently fresh decision inputs.

## Listing and checking are different workload shapes

OpenFGA queries its graph; Cerbos can return a query plan for the application's datastore.

OpenFGA provides native Check, ListObjects, and ListUsers operations over its relationship model. This is a strong fit for sharing graphs and resource-to-principal lookup.

Cerbos CheckResources evaluates known resources. PlanResources returns a condition plan that the application applies to its own database, with reference adapters for several data layers.

The approaches are not interchangeable. Benchmark the largest list query, worst-case traversal, datastore filtering plan, and consistency requirement with production-shaped data.

## Translate decisions, not tuple syntax

Migration is straightforward only when the graph is carrying facts that already exist in the application domain.

| OpenFGA concept | Cerbos | Notes |
| --- | --- | --- |
| Authorization model | Resource and principal policies | Express actions, roles, and contextual rules directly; do not reproduce graph traversal in CEL. |
| Stored relationship tuple | Principal or resource attribute supplied at request time | Read the authoritative domain record and pass only the facts needed by policy. |
| Contextual tuple or condition context | Request auxiliary data or Cerbos Synapse-enriched context | Keep ephemeral facts request-scoped and define their freshness contract. |
| ListObjects | PlanResources plus a datastore adapter | Apply the returned condition in the application datastore and validate result parity. |

### Replace an ownership tuple with an explicit policy condition

`resource_album.yaml`

```yaml
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: album
  rules:
    - actions: ["view"]
      effect: EFFECT_ALLOW
      roles: ["user"]
      condition:
        match:
          expr: request.resource.attr.ownerId == request.principal.id
    - actions: ["view"]
      effect: EFFECT_ALLOW
      roles: ["user"]
      condition:
        match:
          expr: request.principal.attr.teamIds.exists(t, t == request.resource.attr.teamId)
```

This is suitable when ownership and team membership already come from authoritative application data. Keep OpenFGA when the decision requires graph traversal across nested or reverse relationships.

## Where Cerbos is not a graph engine

Cerbos can evaluate relationship facts, but it does not reproduce OpenFGA's stateful graph operations.

| Capability | Cerbos approach | Guidance |
| --- | --- | --- |
| Deep relationship traversal | The Cerbos PDP evaluates supplied attributes. Cerbos Synapse can retrieve graph-derived context, but the Cerbos PDP does not materialize or traverse a relationship graph. | Keep OpenFGA for recursive inheritance and high-fanout sharing graphs, or use both systems with a defined responsibility boundary. |
| Reverse relationship lookup | PlanResources supports principal-to-resource filtering in the application's datastore. Cerbos does not provide a native ListUsers equivalent. | Retain a graph or purpose-built index when resource-to-principal queries are a first-class workload. |
| Managed graph service | Cerbos PDP is a policy decision point; Cerbos Hub manages policy lifecycle and Cerbos Synapse enriches decisions. Neither is a managed OpenFGA tuple store. | Use Auth0 FGA or operate OpenFGA when a managed or self-hosted relationship database is the required architecture. |

## ReBAC inside a multi model engine

Many applications combine relationship-based permissions with attribute and context rules. A relationship-first model can make attribute-heavy policies less direct, although OpenFGA supports many such cases with CEL conditions and contextual data. With the standalone Cerbos PDP, callers resolve relationship context into attributes before evaluation; Cerbos Synapse can perform that enrichment.

Cerbos evaluates ownership, membership, and tenancy when the relevant facts are supplied as request attributes. Commercial Cerbos Synapse runs in customer-controlled infrastructure and can retrieve deeper relationship context from a graph database or system of record at request time. Cerbos Hub Enterprise can manage policy lifecycle and audit on-premise, including in restricted or air-gapped environments.

For reverse relationship queries across very large object sets, a materialized graph is often the more direct architecture. Benchmark the actual model, tuple volume, fanout, list operations, and deployment topology. When graph queries are a corner case, weigh that value against the graph store's operating cost and any synchronization pipeline required by the selected source of truth pattern.

## Cerbos is the stronger default for application authorization

For application authorization that combines roles, attributes, current resource context, policy lifecycle, and deployment control, Cerbos is the stronger overall choice across its open source service PDP, commercial Cerbos Hub-managed WebAssembly ePDP, and commercial Cerbos Synapse layers. OpenFGA remains the stronger fit when deep graph traversal or native ListObjects and ListUsers operations dominate. Prove the boundary with representative check and list workloads, data writes, failure cases, and tail latency.

## Questions you are probably asking

### How much of Zanzibar's production track record transfers to OpenFGA?

Google proved its Zanzibar implementation for Google's workloads and scale. OpenFGA is inspired by that model, but it is a separate implementation with its own deployment, datastore, model, and performance characteristics. Compare those characteristics against your actual workload rather than transferring Google's production evidence wholesale.

### What is the real cost of the tuple store?

Persistent OpenFGA requires a datastore and an operating model. If the same relationship data exists in both the application and OpenFGA, synchronization and reconciliation are additional work. OpenFGA can instead be authoritative for some authorization data or accept contextual tuples. Cerbos PDP removes the relationship store, but the caller or Cerbos Synapse must source the attributes used by each decision.

### Can OpenFGA do attribute conditions?

Yes. Conditions attach CEL expressions to relationships, and contextual tuples carry request data, with published ceilings on request size, evaluation cost, and contextual tuples per request. Cerbos makes these conditions the core policy model. Prototype representative rules in both systems and compare data flow, authoring, and evaluation requirements.

### Should we consider Auth0 FGA instead of self hosting?

Auth0 FGA removes server and database operations, while synchronous checks use an Auth0-managed regional API. Production requires an Enterprise contract, published logs retain seven days, and a dedicated AWS Private Cloud option is available. Compare latency, availability, retention, export, contract terms, and private-cloud requirements against a self-hosted OpenFGA or local Cerbos PDP.

## The short version

**Cerbos strengths**

- Makes attribute and context conditions the core policy model
- Runs the Cerbos PDP without a relationship-tuple database to operate or synchronize
- Can decide locally beside each service, with no Cerbos cloud call in the synchronous path
- Ships opt-in decision logging, policy tests, and query planning in the Apache 2.0 Cerbos PDP
- Commercial Cerbos Synapse can query external systems and inject graph-derived context before Cerbos PDP evaluation
- Adds policy lifecycle, signed distribution, fleet visibility, and audit through Cerbos Hub
- Alex Olivier, Cerbos cofounder and CPO, is one of the current AuthZEN Working Group cochairs
- Publishes public pricing alongside the Apache 2.0 Cerbos PDP

**Weigh with OpenFGA**

- Purpose built relationship traversal and reverse queries at graph scale
- Native ListObjects and ListUsers over the stored graph, within documented limits
- Model tests, editor validation, CLI support, and CI integration
- CNCF incubation and an active community
- A managed option through Auth0 FGA for teams that accept a cloud decision path
- Plan synchronization only when OpenFGA duplicates relationship 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.