yep, previous SRE experience has told me that a schema similar to one we use in postgres probably only starts to struggle with a few hundred million rows, so you should be fine until we cut our next release, haha

ye, think so too 🙂

@User @User I tried to get in touch via your contact form. Didn't get anything back so far, so maybe it didn't arrive.

Is the

prefix/

a global prefix?

Hi folks Im doing a poc with spicedb and trying to understand why a check query is taking 8s after adding some data while before was only 3ms. Looking at the logs seems the problem is somewhere between these two queries:

{"level":"info","module":"pgx","args":[],"pid":10491,"rowCount":1,"sql":"SELECT NOW()","time":1.220158,"time":"2021-10-25T09:38:59Z","message":"Query"}

{"level":"info","module":"pgx","args":["2021-10-25T09:38:54.987366Z"],"pid":10491,"rowCount":1,"sql":"SELECT MIN(id), MAX(id) FROM relation_tuple_transaction WHERE timestamp >= $1","time":8444.964599,"time":"2021-10-25T09:39:08Z","message":"Query"}

Missing an index for that second query maybe?

spicedb=> SELECT MIN(id), MAX(id) FROM relation_tuple_transaction WHERE timestamp >= '2021-10-24T09:38:54.987366Z';
 min | max 
-----+-----
     |    
(1 row)

Time: 8303.089 ms (00:08.303)
spicedb=> CREATE INDEX idx_relation_tuple_transaction_timestamp on relation_tuple_transaction(timestamp);
CREATE INDEX
Time: 5283.843 ms (00:05.284)
spicedb=> SELECT MIN(id), MAX(id) FROM relation_tuple_transaction WHERE timestamp >= '2021-10-24T09:38:54.987366Z';
 min | max 
-----+-----
     |    
(1 row)

Time: 1.142 ms

Much better 🙂

https://github.com/authzed/spicedb/pull/211 raised a pr

Prefixes on authzed.com are globally unique to enable all of our users to share a single, global SpiceDB deployment without name collisions. This might not stay true forever, as we develop multi-tenancy with the community https://github.com/authzed/spicedb/issues/204

Hey guys!

Super excited to see Authzed/SpiceDB going open source 🔥

How'd you go about representing this in a SpiceDB Schema (and relation tuples)? - Organizations has 1..n users - Organizations has 1..n departments - Products belong to exactly 1 organization and 0..n departments Users can be constrained to certain departments, which means that they can only access products belonging to one of these departments: https://play.authzed.com/s/IGzFWyS_XUVK/relationships

I have few questions 1. When we use multiple spicedb instances with same pg database and call check without ZedToken ? Will other instances will get sync their cache after the write call? 2. Can we use redis or something to share cache?

Hey @User - some of it is up to the queries you expect to make, but based on what you said I think you can simplify your schema a bit: https://play.authzed.com/s/Nnr_KymDS8vc/schema The same assertions are valid with this schema, but you don't have to write as many relationships in (we infer the organization of the product by going through the organization of the department) > Products belong to exactly 1 organization I'd also point out that in your schema and the one I posted, nothing is enforcing the "exactly 1" org requirement. Is that something you can enforce from your application, or is there a reason you'd want SpiceDB to enforce that for you?

I'm trying to invite folks to our org, but the email picker dialog doesn't find them, what should I do?

Also, would you setup multiple orgs or multiple schemas within one org to separate dev/test/prod environments?

Hi @User, make sure they have logged into the UI first. We don't (yet) have invitation support in it

@User multiple tenants

No, the other instances will not sync the cache. The idea here is to make use of the peer dispatch system to ensure requests go to the node with the existing cache where possible. We'll be adding documentation and some helpful utilities for intelligent routing in the near future

Is there anyway to subscribe to db changes, so other instances can update the cache?

the watch API provides a means to subscribe and see changes

but none of the SpiceDB nodes will use it to update caches

the reason smart routing is preferred is that you can then store more within the "global" cache, and scale up by adding more SpiceDB nodes

it also dynamically adjusts to traffic patterns

but you could have a proxy that simply watched incoming traffic, marked certain operations for caching, then used the watch API to re-check those cached items

but you'd want to run that as its own service

What do you mean by global cache? And is there any preferred way to deploy multiple instances for HA?

yes, you put them behind a load balancer and it should just work

so long as they are all talking to the same datastore

if SpiceDB is configured with special dispatch flags (see: https://github.com/authzed/spicedb/blob/main/cmd/spicedb/serve.go#L113), then it will know how to dispatch amongst its own cluster

so long as SpiceDB knows where all its peers are, it can intelligently dispatch so that the same "problem" ends up on the same node, thus ensuring the cache-across-the-cluster is used efficiently