Hi, I'm investigating whether spiceDB would be good for our use case and have some questions, a few high-level, and a few low-level, I hope this is the correct place. First off, do you have any data on scaling available? I was planning on running some basic benchmarks but something that would be good to know is how complex relationship hierarchies affect query-times. Something that I was planning on testing is, if we have a user with let's say 5 different ways of reaching a given resource with each nesting once, think user -> group -> resource, and user -> api-key -> resource, etc. With the user in total having access to 10 000 000 unique resources and only one of the ways reach the resource with the given permission required (think all others giving 'read' and only one giving 'write' and we're querying for write), would that give a reasonable query time, where reasonable being at most about 500ms but pereferably less. Assuming single instance postgres as backing. And more to some detail, we're writing the integration in rust so we had to get a hold of the protos, I looked for them in the repo but some I couldn't find and had to pull them from here https://buf.build/authzed/api/tree/main:authzed/api/v1 I was surprised that the *_service.proto files arent easy found in the github source while some of the others are. But I'm not that familiar with go toolchains and this way of distributing protos so it might just be some stupid misunderstanding of how this is managed on my part. What's the preferred way to get client protos?

Hey Marcus 👋🏻 we don't have a deterministic way to figure the performance profile because each schema is different, but we strive to make sure that the system scales linearly with every problem thrown at it. In particular very wide relations as you mention are well understood and we've introduced recent optimizations to handle it well, @Joey can talk more about it. @Jake has also performed some recent performance experiments and can speak for Postgres datastore. re: Rust, we don't have an officially mantained library for Rus, but we keep a list of community mantained ones (https://github.com/authzed/awesome-spicedb) and someone built a Rust library (https://github.com/BitskiCo/authzed-rs) but unfortunately it seems like it hasn't been updated in 10 months, and we've done a lot of changes lately to the API with the new caveats functionality. The API is not found in the spicedb repository, and instead it has its own repository. We generate all the protos from there. The protos inside of the spicedb repository are not API. https://github.com/authzed/api

Ah, I see, that's great to know! It doesn't seem like performance is going to be an issue, we don't have any strict requirements for that either as of now and probably won't for quite a while, knowing that it will scale for the foreseeable future is enough and that seems accurate!

performance is definitely an important focus, and there is more to come - we have big plans. As for libraries, we definitely will be happy to assist y'all with client libraries - I unfortunately haven't learned any Rust, but it feels like the kind of library we should probably support as first-party

@marcusgrass SpiceDB has a number of optimizations expressly around very wide relations: first, if a query is being done to find a terminal subject (such as a user) on a

relation

, we directly look for that specific subject, rather than loading all of them. This change is recent (it merged last week), but it means that if you have, say

relation viewer: user

and there are 1,000,000 users, we'll only check for the 1 requested (or 2 if a wildcard can be there as well). Second: if we walk over a

relation

for an arrow that has many members, like

relation parent: folder

, we perform that walk in batches to reduce the number of requests made. Right now these batches are 100 in size, but we might further increase this in the future to further reduce the work necessary (there is a trade off in parallelism vs larger batch sizes)