We will get the docs updated

dropping this now before we forget: that post got updated with fixed urls today

Hey Team - love your work! I've been playing around in the playground, and getting a feel for SpiceDB and Zanzibar. At the moment, I'm wondering about filtering and listing items, and the lookup. I see that is it is currently "beta". Is there plans to release it? Do you see this as being a full solution for companies wanting a "give me a list of all the items that Alice can see", or will it need to be paired with other solutions? Thanks in advance 🙂

hi @patmac_sc: LookupResources can be used right now and should always work, but it can have significant performance implications, which is why its marked as beta. Longer term we're working to reduce the performance overhead of it, but we're also working on https://github.com/authzed/spicedb/issues/207 as a means of allowing for even faster filtering for much larger datasets

Hi all 👋 I'm looking for a good way to manage schema / data migrations (via a Java app) for an authzed.com hosted instance (i.e. via authzed APIs rather than spiceDB directly). AFAIK, common JVM tools such as Flyway and Liquibase require a JDBC driver to work. If anyone is aware of other tooling or has other suggestions, I'd be grateful. Cheers.

you mean for migration of your schema and its associated relationships?

Yes.

I don't believe there is other tooling right now, but we are working on proposals to address schema migrations with our own tooling

Thanks for your help @Joey . I'll keep an eye out for that. In the meantime, do you think it's feasible for us to write a JDBC driver which leverages the java client? I haven't seriously considered that yet, but I struggle to see how SQL would map to spiceDB relationships. The other alternative of course is to write our own migration library.

I suspect there would be a non trivial amount of effort to map between them

It might just be better to use the API by hand for migrations for now

That’s what we do and it seems to work so far

I want to use spiceDB as central permission-as-a-service solution our ecosystem, how to achieve multi-tenancy with SpiceDB ? Any example would be very useful.

what kind of multi-tenancy are you looking for? strict isolation between permissions systems? or some kind of federation over reads and writes in a single global permissions system?

Hey everyone! 👋 I was reading [dispatch/caching/caching.go](https://github.com/authzed/spicedb/blob/main/internal/dispatch/caching/caching.go) while looking into a memory-use problem with our spicedb containers. Specifically, I was looking at how the cache limits its memory use. Some relevant snippets: https://github.com/authzed/spicedb/blob/a2e9e40fae53b49a6fb183aa0da338011e1eaba6/internal/dispatch/caching/caching.go#L44-L55

go
type checkResultEntry struct {
    response *v1.DispatchCheckResponse
}

type lookupResultEntry struct {
    response *v1.DispatchLookupResponse
}

var (
    checkResultEntryCost       = int64(unsafe.Sizeof(checkResultEntry{}))
    lookupResultEntryEmptyCost = int64(unsafe.Sizeof(lookupResultEntry{}))
)

https://github.com/authzed/spicedb/blob/a2e9e40fae53b49a6fb183aa0da338011e1eaba6/internal/dispatch/caching/caching.go#L222

go
cd.c.Set(requestKey, toCache, checkResultEntryCost)

I am new to Go and could be missing something, but I think that the cost passed to the cache for each item ends up being '8', the size of a struct containing a single pointer field. If the cache max cost is meant to be in terms of bytes of memory used, then I think this would be wrong because the pointed-to

DispatchCheckResponse

could be using much more than 8 bytes of memory. So, a cache that is set to use no more than 16MB of memory, could actually take up whatever memory is used by 2 million

DispatchCheckResponse

structs. The cache config code does state that max size is in terms of bytes: https://github.com/authzed/spicedb/blob/a2e9e40fae53b49a6fb183aa0da338011e1eaba6/pkg/cmd/server/cacheconfig.go#L45-L51 Should the actual memory cost of the

checkResultEntry

struct, including referenced memory, be computed to accurately enforce max cost? Thank you!

i'm trying to get clojure bindings built using

buf

. I've got

protoc-gen-clojure

built and on my $PATH, and i've verified that it works by compiling some

.proto

files using

protoc

. when I try to do

buf generate buf.build/authzed/api

with this

buf.gen.yaml

file:

yaml
version: v1
plugins:
  - name: clojure
    out: src

i get

Failure: plugin clojure: fork/exec /Users/me/.local/bin/protoc-gen-clojure: exec format error

. any guidance on this one? does buf have a limited subset of supported

protoc

plugins?

@yetitwo could you use the Java clinet?

client*

yeah, but it's more cumbersome and we'd have to write wrapper code

its possible you need to specify additional flags

the more direct alternative would be generating the client files using

protoc

directly from the protofiles in the spicedb repo

Buf has a Slack, if you want to ask them in there

re: the additional flags - where would i find documentation on that?

probably best to ask them

I didn't find any obvious docs

I want to use SpiceDB as centrally hosted where many of micro-product apps can use it for Authorization. I am not sure about "or some kind of federation over reads and writes in a single global permissions system?" Please help me to understand this.

Basically you could have completely separate permissions systems, e.g. you could have two different definitions of

user

and they wouldn't overlap or be able to communicate at all. The alternative is that you would have a single permissions system which only has one definition for each object type, and each micro-product can read and write to their own little part of the permissions system, but other things could also do permissions checks that cross those boundaries.

Thanks Jake, Second one sounds ideal for our use case

Yeah, this sounds right. I believe we don't currently do a very good job of keeping track of how much memory is used by the cache. This is something garbage collected languages are notoriously bad at to begin with. We also struggle to estimate or track how much memory is being used by a deserialized proto. We're open to suggestions/contributions.