we expect that some users will even add the

validate

call into a CI/CD process, to ensure no assertions are broken as the schema evolves

longer term, we are investigating ideas around being able to "stage" schema changes, and issue checks against staged schemas so you can also verify/validate on live data as well before promoting

Hi, we are evaluating SpiceDB as our authorization system - thanks for the great product and open sourcing it. We'll need to operate it ourselves, because of EU, GDRP and company policies. So I've read the documentation and on the Datastore side will be probably using just PostgreSQL, because we don't need multi-region deployment and we will probably offloading the PostgreSQL operations to our cloud provider. SpiceDB itself will be running in Kubernetes, but we could not find a documentation on how to operate it in a scaled fashion. There probably is no Kubernetes operator or something like this? Should one of the pods run as a dispatcher and what are the settings for clustered operations?

all of the instances in a deployment are equal peers, and each one dispatches to all of the others using a consistent hash algorithm

all you have to do is configure the

--dispatch-upstream-addr

flag as per this blog post: https://authzed.com/blog/consistent-hash-load-balancing-grpc/

Thanks, I'll read it - I wrongly thought it's about the algorithm only and not about how to deploy it.

We just cut a new release of SpiceDB v1.3.0 https://github.com/authzed/spicedb/releases/tag/v1.3.0

What do you recommend regarding consistency between spicedb and a primary data store? Is it best to treat spicedb as effectively a part of the primary store, rolling back transactions if spicedb is down or fails for some reason? Or is it acceptable to replicate changes to the primary store in an eventually consistent manner? I see some motion in authzed toward things like tailing write ahead logs and what have you. Is there any risk in doing that if replication fails?

hi @User - spicedb doesn't actually store data itself (with exception of its caches); it always treats the underlying datastore as the primary source of truth

I’m referring to like the main application database where all of the actual data lives, and replicating entity ids and relations in that data over to spicedb

ah, I misunderstood

I could have used a less vague term than “primary data store” that’s my fault

there are a few options: you can keep the authorization relationships solely in SpiceDB, and make sure that if the write to it fails, you also rollback your transaction on your primary database

you could also have a worker that synchronizes from one to the other, "catching up" if your "secondary" falls begind

behind*

in our experience, option #1 is generally preferable, since you'll fail the entire operation if the write to both SpiceDB and your primary don't succeed

option #2 is better if you have a means to do something like tailing a WAL and/or there is a means of resuming lookup (typically on an external API or service)

in a previous blog post, we talked about how you can import data from a primary source (in this case Postgres) into SpiceDB: https://authzed.com/blog/zed-import/

and we've done some work on a prototype to use the Postgres WAL to keep the data in sync after that initial import

all of that is currently experimental, but if we find people are interested, we'll explore improving it

Great, thank you for the advice! Having an easy to use tool that can tail the WAL is definitely interesting and certainly seems easier to maintain, but I can’t tell what the risk would be if such a system fell far behind. I think we’ll pursue option 1 at your recommendation and see what you all come up with later on for option 2. I’m sure it will be very cool, just like spicedb itself 😄

my pleasure. keep an eye here and on the blog for any developments 🙂

is it important that object type names be at least 4 characters long?

We are considering relaxing the restriction down to three

For now it is required though

thank you!

Would 3 address your concerns?

Feel free to comment on the issue with your thoughts

3 is perfect, yes