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
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