Enforcer
OpenFGA is a solid Zanzibar implementation. The reason people look elsewhere is almost always the same one, and it is structural rather than a missing feature.
To answer anything, a relationship engine needs a copy of your data. Every time your application creates a project or adds a member you write it twice, once to your database and once to the permissions store. If those disagree, your permissions are wrong and nobody finds out until someone sees something they should not. AuthZed's own CTO names this as the first pain point of the model, so it is not a competitor talking point.
If your problem genuinely is a sharing graph, that cost is worth paying and you should stay. If it is not, you are paying it for nothing.
| Option | Model | Strength | Trade-off |
|---|---|---|---|
| SpiceDB / AuthZed | Relationship | More mature tooling | Identical sync cost |
| Cerbos | Policy, YAML | No sync, stateless, self-host | List filtering is weak |
| Open Policy Agent | Policy, Rego | Ubiquitous in infra | Rego is hard to debug |
| Permit.io | Policy plus gateway | UI, MCP gateway | Still syncs |
| WorkOS FGA | Relationship plus roles | Sign-in included | Resources live in their system |
| Enforcer | Policy over a resolved caller | No sync; identity included | No list filtering |
Keep a relationship engine if you need to answer "list every document this person can see" across an arbitrary sharing graph. That is what Zanzibar was designed for.
Move if your real question is whether this person, in this tenant, with this role and this verification status, may take this action within these limits, and you need to prove afterwards why it was allowed. That is what Enforcer answers, and it does it without a second copy of your data.