Technical decision brief

Cerbos vs OpenFGA

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.

The decision

Choose Cerbos when

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.

Choose 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.

At a glance

What the two models trade

The table describes documented mechanisms. It does not assign winner scores.

Requirement	Cerbos	OpenFGA / Auth0 FGA
Attribute and context decisions	Evaluates CEL conditions over principal, resource, and request attributes as the core model.	Supports conditions and contextual tuples as an extension to the relationship model, with documented limits on context size, evaluation cost, and per request tuples.
Evidence for Attribute and context decisions	EvidenceCerbos resource policies (opens in a new tab)
Relationship graph at scale	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.	Purpose built for the sharing graph shape, with native traversal and reverse queries over stored tuples.
Evidence for Relationship graph at scale	EvidenceCerbos policy evaluation (opens in a new tab)Cerbos Synapse (opens in a new tab)
State and operations	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.	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.
Evidence for State and operations	EvidenceCerbos storage drivers (opens in a new tab)CNCF OpenFGA project (opens in a new tab)
Decision path	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.	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.
Evidence for Decision path	EvidenceCerbos deployment patterns (opens in a new tab)Cerbos Hub embedded PDP (opens in a new tab)
Decision and audit logs	When enabled, emits structured decision logs containing authorization requests, outcomes, and context, with configurable storage backends.	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.
Evidence for Decision and audit logs	EvidenceCerbos audit logging (opens in a new tab)
Listing what a user can access	Returns a filter through the Query Plan API to run against your own database, with ORM adapters.	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.
Evidence for Listing what a user can access	EvidenceCerbos query-plan adapters (opens in a new tab)
Testing and CI	Ships a first class test format and compile checks designed for authorization policies.	Provides model tests, editor validation, CLI support, and CI integration.
Evidence for Testing and CI	EvidenceCerbos policy testing (opens in a new tab)CNCF OpenFGA project (opens in a new tab)
Open source and pricing transparency	Publishes the Cerbos PDP under Apache 2.0 with public pricing and a free tier. Cerbos Hub and Cerbos Synapse are commercial add-ons.	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.
Evidence for Open source and pricing transparency	EvidenceCerbos pricing (opens in a new tab)CNCF OpenFGA project (opens in a new tab)

Deep dive 1

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.

Deep dive 2

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.

Deep dive 3

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.

Implementation

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	Migration or coexistence note
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

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.

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 PDP

Cerbos 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 Hub

Cerbos Synapse

The commercial enrichment and integration layer runs in customer-controlled infrastructure in front of an embedded or external PDP.

Explore Cerbos Synapse

Cerbos capabilities

Follow the implementation details

These pages document the Cerbos mechanisms referenced throughout this comparison.

Testable authorization Permission-aware data filtering Audit logs WebAssembly embedded PDP Policy schemas Flexible deployment models Self-hosted and air-gapped deployment AuthZEN interoperability

Research basis and disclosure

Claims were reviewed against public product documentation, official project material, and standards sources on 24 July 2026.

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

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 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.

Model a requirement with Cerbos

Run the Cerbos PDP tutorial