jschorr

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

However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cache called Leopard that is used for a very specific subset of these relations [2]. For SpiceDB, we called our version of this cache Materialize and it is designed expressly for handling "Enterprise" levels of scale in a similar fashion, as sometimes it is simply too slow to walk these deep graphs in real-time.

We have a guide on doing ACL-aware filtering and listing [2] with this API and describing other approaches for larger Enterprise scales

Disclaimer: I'm the co-founder and CTO of AuthZed, we develop SpiceDB, and I wrote our most recent implementation of LookupResources

Then, I'd take a look at the history of SpiceDB [2] for how we developed the system over time.

Finally, if you have any questions, feel free to jump into our Discord [3] and ask: we're happy to answer!

Generally, the solution is to keep a timestamp of when the data changed (Zookies as you mentioned) or you can proactively reload or recompute the cache when the underlying data changes (sometimes in very smart ways), but yeah: it adds significant complications over a "simplified" approach to Zanzibar.

Disclaimer: I'm the cofounder and CTO of AuthZed and we develop the SpiceDB [2] and Materialize [3], which have quite a bit of logic around these exact problems

However, as you mentioned, life is easier when the main database can handle everything, so we actually built a solution in that space called Materialize [2], which heavily denormalizes the authorization data and allows for joining within application databases such as Postgres. My colleague Evan actually put together a really cool video about using it with Gitea [3].

Recognizing that even with Materialize, however, the need to consume events can be a bit annoying, I've been doing some work to allow Postgres itself to do native JOINs against SpiceDB (and other operations). I demo it briefly in our recent announcements video [4] and I think it effectively solves this problem within Postgres, while still allowing for all the benefits (scale, performance, redundancy, distribution) of externalized authz.