SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions.

SpiceDB

I appreciate all the work you're putting in to this.

I'll try a build of the main line branch and let you know how it goes

On the first couple of tries of what is on mainline, we're getting this

```unable to find revision: ERROR: column "xid" does not exist (SQLSTATE 42703)```

```
2 UNKNOWN: unable to find revision: ERROR: relation "relation_tuple_transaction" does not exist (SQLSTATE 42P01)
```

yes. I just built the image wrong. got past that

```
 ✖ 2 UNKNOWN: max retries exceeded: ERROR: could not serialize access due to read/write dependencies among transactions (SQLSTATE 40001)
 ✖ 2 UNKNOWN: max retries exceeded: unable to delete relationships: ERROR: could not serialize access due to read/write dependencies among transactions (SQLSTATE 40001)
```

How many writes per second are you making?

That just from our initial migration that tends to hang.

the test suite doesn't do that many writes per second. We do batch up as many ops as we can.

I'll try to get the logs from the test suite.

it looks like you're trying to `CREATE` the same relationship twice

That tends to happen when we get the max retires error.

```
{"level":"error","requestID":"fc4464ee5198a6f03c0deb19f015f41e","error":"could not CREATE relationship `resource:alerts#reader@role:readonly#member`, as it already existed. If this is persistent, please switch to TOUCH operations or specify a precondition","time":"2022-10-14T00:06:55Z","message":"received unexpected error"}
```

I don't see the retries error in the logs that you posted

the other thing to keep in mind is that you can still get serialization errors if your transactions actually overlap

e.g. you try to create/touch the same relationship twice from two different processes at the same exact time

can the retries cause this kind of thing even without the error? It tends to happen to me personally than it does to other folks. my computer may just be slower. but same script.

if your transactions regularly overlap, and you get into a retry storm situation things can go south pretty fast

like if you have 3 transactions, and they touch {A,B}, {B,C}, and {A,C} respectively, trying to write those in parallel can end up firing off ~30 requests as they all continously fail due to actually overlapping

or another example would be two transactions where one touches a relationship, and another one deletes that same relationship, this will result in serialization errors when they run concurrently because if you ran them in a different order you would end up with a different end state

I tested a version that used advisory locks to make things wait, but it wasn't fine grained, it essentially serialized all transactions, performance was awful