If you are looking for an OpenFGA alternative, you have probably already built something on it. You modeled your permissions as types and relations, wired tuple writes, one record per relationship such as "anne is a viewer of folder product", into your application, and got checks working.
Now the work around the engine is growing faster than the model. Every feature adds a write path to keep in sync, attribute rules need conditions and context on every call, the list of what a user can see has limits, and someone in security has asked where the decision logs are.
OpenFGA is a CNCF Incubating project maintained by Okta's engineers, and Auth0 FGA offers it as a managed service. The teams we have learned about leave because of what it leaves them to build and run.
Why teams look for an OpenFGA alternative
Keeping a second copy of the data in sync. OpenFGA answers checks from tuples in its own store, so every fact that changes in your database has to be written to OpenFGA too, with no transaction across the two. OpenFGA's own docs say keeping that data in sync "can be challenging" (October 2026). Rover's engineering team replaced OpenFGA with their own Postgres implementation after needing a tuple write for every database write and a cascade system for deletes, and judged change data capture "too much for us to handle".
Attribute rules on top of a relationship model. Real rules mix relationships with amounts, regions, status and time. OpenFGA describes support for "some ABAC scenarios" (attribute-based access control) through conditions in CEL, Google's Common Expression Language, and contextual tuples, facts sent with each request, with published caps on both (October 2026). Each attribute rule means more tuples or more context on every request.
Listing what a user can see. ListObjects, OpenFGA's API for listing the objects a user can access, returns up to 1,000 results within 3 seconds by default, both configurable, and flags a partial list in a response header added in April 2026. Applications that need complete, sorted, paginated lists end up building around it.
Running it in production. Self-hosted OpenFGA means a highly available database, performance tuning as tuple counts grow, and upgrades to test.
Audit evidence. Self-hosted OpenFGA has no decision audit log, and Okta's own comparison page says teams build their own logging. Auth0 FGA keeps logs for 7 days, so anything older is yours to export, store and search, and an auditor asking about a decision from last quarter needs more than a week.
Price visibility. Auth0 FGA does not publish a price. It is billed by the users sent to Check and ListObjects each month, and production needs an Enterprise contract.
Who needs an OpenFGA alternative, and how urgently
Not everyone should move now. Three situations make it worth acting this quarter.
- Sync is already costing you. You have a sync job or change data capture pipeline, you have found tuples that drifted from the database, or new features keep adding write paths.
- Security or audit is asking for evidence. You need decision logs with the policy behind each decision, kept longer than a week, and nobody wants to build that pipeline.
- Authorization is spreading beyond the application. The same rules need to hold at the API gateway, in the data platform or for AI agents, and OpenFGA would need a second engine to get there.
You can wait if the sync is stable, authorization lives only in the application, and nobody needs decision logs yet. Plan the move for when one of those changes.
What to look for in an OpenFGA alternative
These are fair questions to ask any vendor, including us at Cerbos.
- Where does the data behind a decision live? Can it evaluate policy against your database and identity provider directly, or does it need its own copy?
- Can one rule mix relationships and attributes? Owner, team and folder alongside amount, region and status, in one readable policy.
- How does it list what a user can see? A complete answer your database can sort and page, without a result cap.
- What does every decision leave behind? Inputs, outcome and the policy version, kept as long as your auditors need.
- How is a change tested and rolled back? Tests that block a bad change, and a way back in one step.
- Where do decisions run? Next to the workload, and still running if the control plane is unreachable.
- How far does it reach? Applications, gateways, data platforms and AI agents from the same policies.
- Is it on a standard? AuthZEN support means your application's calls stay the same if you change decision service.
- Can you see the price before the sales call?
For a full breakdown of what to look for when selecting an authorization solution - refer to our detailed framework.
The main types of OpenFGA alternative
Most options fall into one of four groups.
Other ReBAC engines. Other ReBAC (relationship-based access control) engines modeled on Google's Zanzibar paper work the same way OpenFGA does, storing relationships as tuples and following them to an answer. A move between them changes the engine but keeps the second copy of your data and the sync work.
Stateless policy decision points. A decision point evaluates readable policies against attributes the application sends, or that are fetched for it at decision time, and keeps no copy of your data. Relationships become conditions, and lists come from your database through a filter. This is the model Cerbos uses, and it is the one that removes the sync.
General purpose policy engines. Engines built for infrastructure policy, such as Kubernetes admission control, can be used for applications too. They are flexible, but roles, resources and relationships have to be built on top, and lifecycle tooling is yours to assemble. Our Cerbos vs OPA comparison covers that trade-off.
Building it yourself. Some teams move authorization back into application code or database functions. It removes the vendor and brings back scattered checks, no central audit and every rule change as a code deploy. Our post on build vs buy authorization works through the cost.
Cerbos as an OpenFGA alternative
Cerbos is an authorization management platform. Cerbos PDP, the policy decision point, runs next to every workload and evaluates your policies on each request against the attributes it receives. Cerbos Hub builds, tests and distributes policy and collects decision logs from every decision point. Cerbos Synapse fetches context from your databases and identity providers at decision time and connects gateways, data platforms and AI agents. The platform runs more than 2 billion authorization checks a month.
Decisions from your data, with no tuple store
The facts your tuples hold today, owner, team, folder, organization, are almost always columns and join tables in your database already. In Cerbos the application sends them with the request, or Cerbos Synapse reads them at decision time from the database, directory or identity provider that owns them. There is no dual write, no sync job and nothing to drift.
Relationships and attributes in one policy
Relations become derived roles, roles granted for one request when a condition comparing the person and the resource is true, such as "editor of any folder above this document", and attribute checks sit in the same condition. Both products use CEL for conditions, so your OpenFGA conditions carry across almost as written. Policies are YAML that security and product reviewers can read in a pull request.
Lists from your database, without a result cap
A query plan turns the policy into a filter your ORM adds to the query it already runs, so the database returns the rows a person may see, sorted and paginated, with no cap on the number of results. Data teams call this predicate pushdown, the access rule travels down into the database query instead of being applied to a list afterwards. Adapters cover Prisma, Drizzle, Mongoose, Convex, SQLAlchemy and LangChain with ChromaDB.
Decision logs your auditors can use
Every decision is logged with its inputs, outcome and the policy version that made it, and Cerbos Hub collects them from every decision point, kept for up to a year on Production and longer on Enterprise. Hub also runs your test suites on every change, only builds when they pass, and rolls back in one step.
One set of policies beyond the application
The same policies govern API gateways (Envoy, Istio, Kong, Apigee), Trino row filters and column masks, Kafka topics, Kubernetes admission, and AI agent tool calls down to their arguments, through agent hooks, MCP gateways or the MCP server itself.
Published pricing and a standard API
Cerbos pricing is public, from a $0 proof of concept tier to Production from $933 a month. Cerbos PDP implements the AuthZEN Authorization API, and SDKs cover Go, Java, JavaScript, .NET, PHP, Python, Ruby and Rust, every language OpenFGA ships an SDK for and more. Alex Olivier, our cofounder and CPO, co-chairs the AuthZEN Working Group.
For a side by side breakdown, see Cerbos vs OpenFGA.
When Cerbos is not the right OpenFGA alternative
Cerbos resolves relationships as attributes. One or two hops are a single condition, and for nested folders Cerbos Synapse queries the folder tree before the check and returns the folders a person can reach. That covers most application models.
If your product's core question is reachability through a very large sharing graph with many hops, test that part with your real data before you start, and move the rest of authorization first. Listing every user with access to an object stays a query on your shares and members tables.
Moving off OpenFGA without a big bang cutover
Whichever alternative you choose, the safe pattern is the same. List your types and relations and the tuples behind each one. For each tuple family, decide where the fact comes from afterwards, a column your database already has or a lookup at decision time. Translate one resource type, port its model tests, and run the new system beside OpenFGA on real requests without enforcing its answer. Log every disagreement and fix the cause. Cut that resource type over behind a feature flag once the disagreements stop, then stop writing its tuples. Repeat for the next.
OpenFGA's own adoption guidance describes running two systems side by side and comparing, so this is a pattern its users already know. Our OpenFGA to Cerbos migration guide covers each step with a worked translation, list filtering and the comparison code.
For most teams leaving OpenFGA, Cerbos is the right alternative. It removes the second copy of the data and adds the decision record OpenFGA leaves you to build.
Try Cerbos with one of your own OpenFGA models. Your engineers keep the ORM and queries they already use for lists, your identity team keeps its identity provider as the source of truth for groups and roles, read at decision time, and your security team can approve gateways and AI agents under the same policies as the applications. To plan the move from OpenFGA, book a call with our team, bring a model, and leave with a migration plan your security and audit teams can review.
Go deeper:
FAQ
Tagged in
