Unlikely. Seems to be checking permissions against postgres.

Odd

I'd have to get more info to say more. Could have been a fluke.

Maybe it’s the same timezone issue we’re currently addressing

ah, thanks! that's basically exactly what I wanted. the only worry I have is how does this scale with having 10s or 100s of potential relations in a single definition?

(by potential relations I mean having different relation types e.g. issue_creator, issue_assigner, etc)

it will make the schema namespaces slightly slower to load and parse, but they get cached making that cost amortized

i can't think of any other scaling problems

is there something in particular you're worried about?

not anything specifically at the moment, just making sure that it is viable to do it and not inherently unscalable in the future.

should be fine, if you run into anything let us know and we'll get to work on fixing it!

awesome, thanks! the only other question I might have is whether CRDB is fully supported or are there things I should look out for?

we run CRDB in prod

that answers that

this is some interesting reading if you've got the time: https://authzed.com/blog/prevent-newenemy-cockroachdb/

ah, I saw this issue mentioned in the docs, will have a read, thanks!

qq: is spicedb’s cockroach support reliant on enterprise features or is standard cockroach ok?

you'll probably want backups

but we don't orchestrate that, and we don't use any other enterprise features, e.g. enterprise changefeeds

I'm regularly getting some of these errors when calling the check endpoint:

Could not check permissions from the SpiceDB service. Error: 2 UNKNOWN: error dispatching request: unable to read namespace config: context canceled
    at Object.callErrorFromStatus (/home/node/app/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/home/node/app/node_modules/@grpc/grpc-js/build/src/client.js:180:52)
    at Object.onReceiveStatus (/home/node/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:365:141)
    at Object.onReceiveStatus (/home/node/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:328:181)
    at /home/node/app/node_modules/@grpc/grpc-js/build/src/call-stream.js:182:78
    at processTicksAndRejections (internal/process/task_queues.js:77:11) {
  code: 2,
  details: 'error dispatching request: unable to read namespace config: context canceled',
  metadata: Metadata {
    internalRepr: Map(2) {
      'io.spicedb.respmeta.dispatchedoperationscount' => [Array],
      'io.spicedb.respmeta.cachedoperationscount' => [Array]
    },
    options: {}
  }
}

That seems like an internal error, either it's a bug or it should surface a more readable error for the developer? "namespace config" and "context canceled" aren't concepts I've encountered in the docs

what datastore are you using?

Postgres 12, on RDS Aurora

It seems to be correlated with writing a lot of data? It started to happen much more when I started a long-running process to load a bunch of data in spicedb

its possible the system is getting CPU starved

Hello, Is there any benchmarking / performance numbers published on how SpiceDB operates for 1. Checking a relation (assume it to be pretty fast) 2. Lookups / Expand (I believe if there is a real high volume of user who has a certain relation to a subject ) lookup of all users based on the relation with a subject may be a costly operation (assuming no pagination support in place all users will be returned back)

> its possible the system is getting CPU starved The SpiceDB instance or the DB? I'm assuming the former: surely that shouldn't result in an internal error?

SpiceDB and it could

if the requests are timing out they could be canceled

Shouldn't I receive a clear timeout error in this case?

Another, more important, issue I'm encountering: when writing to SpiceDB I'm receiving these errors:

unable to write tuples: ERROR: duplicate key value violates unique constraint \"uq_relation_tuple_living\" (SQLSTATE 23505)

It happens from time to time when I'm writing relationships 1-by-1, and it happens systematically when I'm writing relationships in batches of ~4000. It happens when I have only 1 instance of SpiceDB and only 1 process calling SpiceDB, without parallelism, so it doesn't seem like it could be a race condition