probably

but then you'll have read-after-write issues

unless that's not a concern

sure sure, but in our case this is acceptable

nothing is uber sensitive for us, aka a user gets permissions infrequently so unlikely to request quickly after getting a permission and if they have access for a few moments after a permission is revoked that's cool too

if we run on crdb is the permissions table a global table then to ensure consistency? or can we configure regional by row to keep writes fast?

(sorry thank you for answering all these quetions, super helpful, spicedb is #1 choice right now but just worried about operational overhead)

its a global table but CRDB handles things for you

because it coordinates writes such that we cannot end up in a bad state

if you'd like to use PG as per the issue, @williamdclt might be able to help (as he wrote the comment you linked)

gotcha, in that caes though we may have really bad write perf though (multiple seconds?) if we have a global cluster? for example if we're running in asia, south america, europe unless we use super regions?

yes, that could be an issue: there have been discussions about setting per-row geo tags, but its still theoretical

cool, yeah regional by row would be killer

okay thanks for all the help, lots to think about

with the serverless offering, it looks like you'll be multiregion soon, any idea when that might roll out?

multiregion support will be in Dedicated; outside of that is TBD

gotcha thanks!

hello, im observing this project for the first time. is there any simple docs that explain how spicedb works in contrast with postgreSQL? does it cache stuff? how does it cache etc.

yes, there is a cache: https://authzed.com/blog/spicedb-architecture#caching-dispatch

oh so, there is clientside + serverside cache? how does client get notified that its cache is stale?

it expires after a predetermined period of time

am i limited to using one schema file or is there a way to import from files to files, to have some kind of a folder structure in case my permission arch grows?

single file right now

we recommend combining it via a CI process

any other vscode/goland plugins for zed files? i found this https://github.com/chiperific/vscode_authzed_syntax

How does the cache interact with the new enemy problem? If I revoke a permission even with a consistent data store am I at risk of a bad read via the cache or do the revision numbers protect against that?

that's what ZedTokens are for: you send a ZedToken with

at_least_as_fresh

and SpiceDB ensures the cache entry used (if any) conforms to that point in time

Is there a way to support transactions, or perhaps a way to ask "If I were to add or remove these relationships, now which users have permission?" I'm looking for a way for users to confirm that they actually want the changes they're proposing by showing them a preview of the consequences.

Hi, regarding the experiemental API and BulkCheckPermission action. The API returns a Pair of Request and Response. However, from the client perspective, what is the best way to deal with the response? The clients will have the list of permissions they want to check and they receive back the same Requests and the Responses. What is the most optimal way to access them? I mean, there still needs to be an iteration over the result to find the response (bool) for the provided request. But to identify the request they need to do some processing like: give me the response for the request with this resource type and id, this relation and this subject type and id, right? Wouldn't it be better to have something like a UUID in the

BulkCheckPermissionPair

so that we can easily access a request directly? Or maybe I'm missing something. Thanks!