the folder is the subject

Thank you! Makes sense

Actually, I dont think the zed cli will work within my pipeline. I think I will have to use the rest endpoint to write the schema. Is there a simple way to convert the .zed file into a string that the rest endpoint accepts?

It’s the same string

Another question hehe How much more performant is lookUpSubjects and lookUpResources compared to readRelationships? Or are they similar?

if reading a single relation, same performance. otherwise, LR/LS is strictly less performant, as it would have to read multiple relations, vs read which is a single relation

Thanks! And overall, what are the caveats of using readRelationships? I understand it should be avoided when possible, but when does it become problematic? Is it a factor of how many relationships the database have in total?

I mean, what are you trying to accomplish?

So I have an RBAC modeled in spicedb. Users can be member of roles. To get all roles a user is member of, I]m currently using readRelationships. Could that eventually become a problem?

so long as you use a limit+cursoring, it should be fine

at some point it will become problematic for the caller, but SpiceDB should be okay with it: its a simple direct lookup

vs LR which is computed

You mean problematic for the caller in the sense it starts returning too many relationships? Cause I dont think that will be my case

yup

Cool. I'll stick with it then! Thanks!

It shouldn't be a problem for the underlying database either, right? Not sure how these lookups (with readRelationships) are indexed

depends on what you're using as a filter

Do you have any recommendations for fully managed services or platforms to host SpiceDB? We are evaluating the product and were looking for someplace where I do not have to manage the infrastructure myself.

That's our primary business model: https://authzed.com/products/authzed-dedicated for dedicated installs and https://authzed.com/z/authzed-cloud-waitlist for the upcoming Cloud environment

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.

I have upgraded spicedb from 39 to 44.4 and in logs I can see there are continuous db call insertions to relation_tuple_transaction How to stop these calls and why is it happening

I've been told that I need to run the

spicedb datastore repair

command on my postgres read replicas before updating my spiceDB deployment to use them. Two questions: * Is this command safe to run multiple times? * Will I need to run this command again if we upgrade our read replica instances in AWS?

1. yes 1. you shouldn't

Awesome. Thanks a bunch!

if you want to know how/why you need to run it that command, it's in my recent POSETTE talk:

hey folks! We are evaluating using SpiceDB at our company and I wanted to clarify something -- without the enterprise license you cannot have a way to do any sort of role based access control on the SpiceDB APIs themselves, is this right? From my reading you have to use PSKs, which would mean that any workload can have more then just "check permissions", it could also say change the policy, etc. If this is right then how is the open source version supposed to be hosted? Is the idea that we have to build some kind of service to front SpiceDB to ensure only the "check permission" API is allowed to be called by workloads (or obviously we can also get the enterprise version -- which isn't out of the question, just trying to understand).

That's correct. The PSKs in open source SpiceDB are solely used for authenticating the service to SpiceDB. Once you've authenticated, you have full access to the SpiceDB. SpiceDB Enterprise (self-hosted) and AuthZed's Dedicated Cloud platform (managed) ship with the ability to control what each PSK can actually perform on the API. If you want this functionality, we'd obviously prefer you use one of the paid products otherwise you'd have to do as you say and build something in front of SpiceDB which further adds latency and additional complexity that could lead to privilege escalation if misconfigured/buggy.

thank you so much! that makes total sense

the "fronting service" is how we did it at my old company

thanks! yeah that makes sense