and images are published to ghcr, dockerhub, and quay

We link them in each release: https://github.com/authzed/spicedb/releases/tag/v1.7.1

Great! thanks.

Hi all! How does spicedb compare to keto which claims to be an open source implementation of Zanzibar?

I haven’t checked on keto in a while, but last I checked it was missing major Zanzibar feature like relationship rewrites, tuple to userset, and redispatch

Not to mention the things we have added on top such as our schema language and the LookupResources API

What about the performance?

Keto loads everything in ram while spicedb fetches from database with cache, does this mean that keto will perform better atleast in smaller datasets?

@ukanwat if your dataset is small enough, you can use the memdb driver and run SpiceDB in a single-node confirmation to have everything loaded into memory. That being said, for any "real world" system, the data being accessed will almost certainly be too large or changing too rapidly for it to live solely within memory and still meet consistency requirements

What if I use postgres with a large dataset would this setup perform better than keto or opa? OPA has a pull data during evaluation feature (https://www.openpolicyagent.org/docs/latest/external-data/#option-5-pull-data-during-evaluation) which might be similar to how spicedb works. Apart from some complexity, are there any drawbacks of using this feature instead of spicedb for building an authorization server?

As keto is missing key Zanzibar features, it is hard to compare against, as it likely will not meet the requirements for use

"better" depends heavily on what your dataset looks like and what consistency you require. however, in general: OPA's defaults do not ensure that you won't evaluate against stale data, which is a key guarantee of a Zanzibar-like system. Furthermore, since caching is built in and automatically handled by SpiceDB, you get the benefits of automatic caching and scaling, which OPA (AFAIK) does not provide

the reasons Google moved from a policy-engine-based system (ala OPA) to Zanzibar were primarily because, in their experience, a policy based system neither scales as well, nor provides the staleness guarantees

That's interesting point, in your explanation consistency/ staleness is well explained due to lack of database, but I am not able to relate it to Scalability limitation, can you please help me to understand that, your explanation much appreciated !

Hi I am calling

WriteRelationships

to update an existing relationship. Do I need to delete the existing relationship before writing the new one or spicedb automatically updates for me? Thank you

@HOPE if you use TOUCH, then you can just write it

If you use CREATE, then if the relationship exists, the write will fail

I did use CREATE, thank you!

Is there any upgrade planned in near future? If yes what all issues addressed in SpiceDB ?

@Singha1 you mean a new release of SpiceDB?

yes

Yes, we usually release once a month or so, but it depends on what has been merged and when. There is a new release being tested right now; if you want to try it yourself, you can check out the main branch

Just be aware the main branch is considered unstable until it is released

re: performance, based on my limited experience with these kinds of systems, it seems that OPA is generally considered to be slower, or at least less scaleable, because it's easier to write logic into it that takes longer to calculate

and the tradeoff between it and rebac is that OPA (and other ABAC systems) are more flexible - they can be stateful and temporal in ways that rebac systems can't

question of my own: we're looking at a spiceDB implementation, and one of the hurdles as far as my team is concerned is that we don't want to expose a notion of zedtokens if we don't have to, because it's seen as an implementation detail that we'd prefer to abstract over if possible. how would I go about selling them to my team? I saw the bit in the docs where you say > Really, though, you should store ZedTokens. my sense is that it's because otherwise you're choosing either inconsistency in the form of the New Enemy Problem or performance degradation in the form of spiky latency. that part's all well and good, but i can hear my team trying to engineer around it by sticking redis in front of it and storing zedtokens there or some other approach... is there a neat way of explaining it?

hmm... i suppose one way of approaching it is saying that a rebac system is essentially a cache over the existing data model of the system, and in order for a cache to work well you need to know when to invalidate it, which involves the system querying the cache having some notion of the cache state.

not even essentially: actually

there is an actual cache and the ZedTokens do inform when the cache can be used

that's the entire purpose