Looking up indirect subjects, our schema represents something like this:

definition user {}

definition person {
    relation owner: tenant
    relation representation: user

    permission view = owner->member
}

definition tenant {
    relation member: person#representation
}

Now we are seeing an big performance hit looking up if user:a can see person:b, when an tenant has a lot of members (> 10k). It follows the following path:

✓ person:william view
└── ✓ tenant:main member
    └── ✓ person:jan,john,joost,william representation
        └── user:3

It first looks up all the people that are a member of our tenant, then it loops through all the people until it finds the user (representation) with id 3. Any recommendations on how we could handle this lookup more efficiently? We would like to keep our abstraction of an user representing a person instead of making users direct members of the tenant.

it's basically expected when you have a schema structure like this. what's the business logic that led to this structure? like what's the use case?

So people are entities that are managed by people, but not all people can login. People that can login are represented by an user, which is identified by its id in an authentication server, e.g. keycloak.

ah, so like an hr software sort of use case?

Yeah, its like that. An user "admin/ manager" can manage its people, but the "admin/ manager" can also manage itself or other "admin/ manager"s

so this is a LookupSubjects with a specific

person

as the resource and

view

as the permission?

Yes, also when checking the permission e.g.

zed permission check person:william view user:3

yeah, i don't think there's a way to work around the fact that

member

is a wide relation.

Yeah there are two solutions avoiding this whole problem. Indeed, attaching the users directly to the tenant as members. Or resolving the person and throwing out the whole user definition.

but something is writing the relation between the user and the person, yeah?

I am sure it can 🙂

sure thing! and it's theoretically something that will improve as we continue to optimize SpiceDB and implement a graph query planner - as much as possible we'd like to make business logic performant and avoid needing structural workarounds to problems

for now, you can also change your chunk size from

100

(the default) to

1000

(or more), which should help

Doubt that that is really making an impact on our setup, we see it blocking in it's

QueryRelationships

relation call for more than 10 seconds.

in check?

Yes, specificly the CheckBulkPermissions.

that seems concerning; even selecting 10K rows from a table shouldn't take 10s

The 10s is the worst case scenario. With >200k members on 1 tenant, we see performance impact starting from >10k.