We should develop and translate this extension to other databases.
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.
[1]: https://authzed.com/docs/spicedb/modeling/protecting-a-list-...
[2]: https://authzed.com/products/authzed-materialize
[3]: https://www.youtube.com/live/u3i1SEd9Ll8?si=mCz5mZterxthoEwj
[4]: https://www.youtube.com/live/uz_gxz3whS0?si=g4NUZAIltYVyFzYj...
Disclaimer: I'm cofounder and CTO at AuthZed and we build SpiceDB and Materialize
This is a fundamental problem with all Zanzibar-inspired authorization systems[0] that require centralizing ~all authorization data and led us @ Oso to build a more flexible system[1] that grants more control over what authorization-relevant data you centralize vs. decide keep locally.
0: https://www.osohq.com/post/authorization-for-the-rest-of-us
1: https://www.osohq.com/docs/develop/facts/local-authorization
disclosure: founding engineer at Oso
ygouzerh•1h ago