I think one major difference between the Zanzibar implementations that are out there is support for the 'zookie' consistency token (as mentioned in the original paper). OpenFGA afaik doesn't implement zookies yet[1]. With zookies, each permission write generates a unique token that represents that particular write. Clients can store that token (per resource) and optionally provide it during runtime checks to ensure checks are consistent up to that write. It also helps the system guard against the 'new-enemy problem' (incorrect permissions checks due to permissions changes being read out of order) by ordering writes.

I'd argue that it also unlocks a variety of caching implementations on the Zanzibar server while still allowing clients to specify desired consistency on a per-request/per-resource level. In other words, a Zanzibar implementation with support for zookies can guarantee consistency at a much higher throughput than one that relies on time (second, millisecond delay). This is important for generic 'read after write' scenarios.

Disclaimer: I'm a former founder of Warrant[2] which was recently acquired by WorkOS. Our team has spent a ton of time building our Zanzibar-based authorization service (WorkOS FGA[3]) which supports zookies[4] and other Zanzibar concepts.

[1] https://openfga.dev/docs/interacting/consistency#future-work

[2] https://warrant.dev/

[3] https://workos.com/docs/fga

[4] https://workos.com/docs/fga/warrant-tokens

Hi there, Ege from Permify here.

Here are the major differences,

- Better Performance: Observed guess, not necessarily a fact: Many folks have come to us from OpenFGA due to latency and performance issues. We’re implementing various levels of caching mechanisms to meet the required performance. We have also documented the differences in caching between us and OpenFGA in the following document: https://permify.notion.site/Cache-Differences-Between-Permif....

- Schema Management: We're taking an approach that help engineering teams to ease and streamline the management and collaboration of their authorization logic. We have features like:

  - Schema Staging: Handle authorization model (schema) changes at different stages and deploy schemas with our GitOps workflow, specifically designed to approve, merge, and monitor schema changes.
  - Partial Schema Update: Gives you the ability to update a schema partially without needing to change the entire schema.
  - Data Bundles: Handle multiple data creation and deletion actions in your applications.