> Checking activity:x#view seems to blow up our database due to needing to evaluate thousands of capability per subject yeah, we call this the "wide relation" problem. it's theoretically something that we'll be able to optimize around in the future as we start figuring out statistics and query planning, but right now when this condition is encountered it just has to evaluate a lot of tuples. we're also looking at an API for checks/LRs where you could provide a relation that the walk has to go through, which would potentially reduce the amount of work that needs to be done: https://github.com/authzed/spicedb/issues/1317 in the meantime, though, yeah, we usually recommend scaling up your db as the first step. in our experience, keeping PG and cockroach CPU usage below 60% is a decent heuristic. another thing that might be worth looking at is using a self relation to express binary logic instead of wildcards:

definition activity {
  relation subject: subject
  relation official_content: activity

  permission has_official_content = subject->official_content
  permission view = official_content->has_official_content
}

with the idea being that you'd write an

official_content

relation from an activity to itself to mark that boolean. this isn't necessarily the optimization that's going to fix things, but using arrows instead of intersections means that SpiceDB doesn't have to evaluate as many tuples before it can decide that it's got a match, and you can propagate that same pattern up the tree