do you have a PR number / link. just for my own curiosity

Hmm. Our problem isn't with the spicedb migrations specifically. just trying to do many thing

or is it all inter-related

that PR contains the migrations to move Postgres to new data model for better write parallelism

I'm interested in finding some hardware requirements for SpiceDB, hopefully in relation to scale in RPS. Is there anything like that published?

it highly depends on the size of the nodes you intend to run and the complexity of your schema; if the nodes are smaller, you'll need more to allow for higher RPS.

When deleting entities on our end, is there a simple way to cleanup all relationships that are bound directly to that entity via the zed client?

I found this open issue: https://github.com/authzed/spicedb/issues/315

I hope this is what it is. Our application test suite runs many tests in parallel and they all try to do some kind of spicedb setup work. its starting to not work more than it works for us.

Parallel testing should be using the test server and not a real datastore unless you need to test performance

what?

You’re running SpiceDB against Postgres for the purposes of unit or integration testing?

integration testing yes. the application has to go through CI before it can be released

Unless you need the full Postgres data store, we recommend using serve testing command for tests

I don't know what that means. serve testing command?

hmm. so what happens when we put this in production and people are using it for real. there will be parallel writes.

The newest (unreleased) version of the postgres driver is MUCH better at parallel writes

that's what joey referred you to earlier

I'm putting a lot of eggs in that basket

you can feel free to pull it down from main and test it out yourself, just don't use it for any production workloads until it is released

what causes the problem with high write throughput?

serializable transactions on a table with an autoincrement primary key

here was the first chunk of that work: https://github.com/authzed/spicedb/pull/852

oh, we need to enable

track_commit_timestamp

?

Only for the watch API and its eventual consumers

hmm. like

NEXTVAL

is a bottle neck?

I miss what postgres does as a database, Looking through these PRs, I don't miss hand generating SQL queries 😂

We try to generate a lot of the queries with a library called squirrel, especially for ones that need dynamic predicates. This change was too close to Postgres internals for that to work though.