maybe, it is possible after all.

if indeed gRPC health-checks won't work, is that an open/unprotected route that i could use?

do i have to pass

Authorization

header to check health via HTTP gateway, or it could be done anonymously?

I haven't tried in a while, but I believe the http gateway

/healthz

endpoint doesn't require auth

i will check

/healthz

out. also, will try AWS instructions. as they seem quite doable as well. will follow-up here. thank you @ecordell and @Joey

Hey guys, we've been using SpiceDB in production for a few months now at https://www.veed.io and have gradually been migrating our authorization data to it. We've attached a Postgres datasource, which now has a size of about 7GB and we've run into a bit of an unexpected problem. The easiest way to explain it is by showing some metrics. As our data size grew from about 2-3 million datapoints to >10 million, we started noticing significant slowdowns on some user accounts, but not on others. Following the documentation, we had implemented ZedToken caching and use

atLeastAsFresh

consistency for a number of our users - which we found to be the exact users having issues with significant slowdowns. Our investigation into the issue resulted in the discovery that making use of ZedTokens actually slowed down requests by a factor of 100. We've now set everything to be fully consistent, and as you can see in the metrics, slowdowns have stopped, but this isn't the behaviour I'd expect. Is this something you've run into before? I'd be happy to create an issue on Github and/or provide more metrics to help you gain insights here. I'd expect full consistency to start causing problems if our data set grows by another 50 million data points

@sjaakiejj indeed that does not sound right, would you mind opening an issue?

Hi all, Just a quick question in case it's a simple answer before I go digging. We're running spicedb with a postgres datasource and we've been seeing some unique index constraint violations on the relation_tuple table for uq_relation_tuple_living. This is caused by a sequence of write relationship -> delete relationship -> write relationship requests. I've had a look at the buf docs for both and we aren't using any optional preconditions, so I'm not sure why this is occurring? As far as I'm aware the delete transaction should have committed long before the write request comes through. Cheers

hi Andy, are these requests concurrent or in sequence?

sequential

as a result of 3 separate API calls basically

can you give an example sequence of some relationship(s) that cause it?

i.e. is it the same relationship being CREATEd and then deleted, and then CREATEd again, or?

yes

the create will technically be identical

okay

we'll see if we can repro

we do know that if you create the same relationship within a single write call, it can raise an error; we've clarified that error in HEAD

thanks a bunch - let me know if you need any more info

Hey all, I'm currently evaluating using SpiceDB as my company's new authorization system. Is there any documentation for how to set up a multi-instance cluster? I see a bunch of dispatch flags on the serve command, but I'm not fully clear on what's needed to get multiple instances into a single cluster.

are you running under Kubernetes or would you cluster "manually"?

This would be under Kubernetes.

there is a Helm chart that someone in the community put together to make it easier, but I'd recommend waiting a few days, when we have an announcement that will make running a cluster under Kubernetes much easier

Ok. Cool.

Alright I'll open up an issue on Github, thanks!

do you happen to have any timing information on the API calls?

I've asked a colleague if they can grab them, currently out

Will get back to you

no rush 🙂

It's definitely synchronous though as it's three separate http calls and we're only updating the UI on success each time, so it seems like something locking up in spicedb and not committing in time