The main pain points around using a Zanzibar-like approach (typically called Relationship-based access control) are:

(1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres

(2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects.

(3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC. The separation of the search index and the permissions database makes it harder to integrate and computing permissions, at scale, is incredibly complex. For SpiceDB, we have Materialize to help solve this problem [2].

[1] https://github.com/authzed/spicedb/tree/e9d636d2b58dd9e92c44...

[2] https://authzed.com/docs/authzed/concepts/authzed-materializ...

Disclaimer: I'm CTO and cofounder of AuthZed and we build SpiceDB (https://spicedb.io), the most scalable OSS implementation of Zanzibar