permissionship of

0

is fine; its the fallback on the current code

the next version will use that field

are there any practical (or otherwise) limits on the lookup-resources endpoint? I'm looking at a use case with multiple levels of categories that can be shared with users. I'm thinking that the server would call authzed and do a lookup on the subcategories the user is able to view, and then do a db lookup for items in those subcategories. However, there could be upwards of 50k subcategories in a single result

yes, the more resources the system needs to traverse, the longer it will take

practically speaking, you can just keep streaming back results until the timeout is hit

but how long it takes depends highly on the structure of your schema and data

see https://github.com/authzed/spicedb/issues/207 for the current proposal and discussion on how we might speed this up

Is there any way to reason about what makes a schema more complex? Is it just nesting, or logical operators in permission calculations, or computed usersets, or ... all of the above? Are any of those things higher cost than others? Also, do you know the status on that proposal? I see some PRs and activity recently, but that doesn't really inform me of when the feature might land

is 50k possible with some schema, or just never going to work?

nesting means having to follow additional data levels

intersections, exclusions and caveats means having to issue followup checks

so the latter is definitely higher cost

it'll work, but it might time out; now, if you're running SpiceDB yourself or using Authzed Dedicated, that timeout can be adjusted

we've done a lot of work to make the performance for larger lookups better

status is that its still in discussion and experimentation; I'm the proposal writer and I've been doing additional research on it recently

ok, thanks for the info!

best bet is to test it locally and see what you get based on your own schema and data

if you're not using intersections, exclusions or caveats, it could be relatively quick

since it just means bulk SQL queries

Question - Are there performance concerns with using wildcards? Is a check using a wildcard performed in constant time?

more or less, yes. basically, instead of checking for the target subject like

user:ethan

, we check for either

user:ethan

or

user:*

the overhead should be negligible

where wildcards can add some overhead is on LookupResources: since it needs to return all accessible resources, if you have many marked as public, then that means returning all of those as well

That's a good consideration - I see that LookupResources returns a stream. Would you expect any negative impact on the database if I queried something with a large dataset behind the wildcard, like all users? Or does the impact depend on how quickly I process that stream? https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.LookupResources

I wouldn't say "negative", so much as it is load you'd need to consider

LookupResources is a reverse graph walk: it starts at the specific user (and

user:*

if allowed) and follows any incoming relationships until it reaches the resource for which the call is being made

so if you have a lot of starting subjects

it can mean more load on the service and DB

SpiceDB will batch them together, however

so its not a huge amount of overhead