i'm not sure i understand the use case or the reasoning. one thing to call out is that the Zanzibar model that SpiceDB is based on makes an assumption that you centralize all of the data required to make an authorization decision. if you violate that assumption you're probably going to have a bad time. how did you land on the architecture that you're describing? what constraints are you worried about?

In the full hierarchy we would have billions of nodes, while the actual permissions are set on 100s-1000s of them. Also it's a data mesh, so we would rather not store all the data within SpiceDB, but just a subset and it's relationships. Hence the question.

but is there some connected subgraph of the hierarchy that you're computing permissions on?

It's connected for permissions checks. Let's say we have 2 million folders that go 50 levels deep, and 100M files. Permission could be set on level 1 and 5 of the graph, so we could just represent the permission graph as "root->folder1->folder 5", and when someone checks access to file below folder 5, we can just check permissions on first ancestor and evaluate up this small graph as needed.

hmm... yeah. i suppose you could also do the bookkeeping outside of SpiceDB and only represent the relevant nodes for the permission check in SpiceDB