Hey team, are schema writes idempotent in SpiceDB? If the write command is called, but there are no changes, will a new revision be created? It will make my deployment flow a lot easier if I can call write on every app deployment without having to check if there has been a change to the schema Also, any details on how multiple concurrent schema updates are handled? What happens if two (or even 10) schema writes happen simultaneously, do they get executed sequentially?

> Hey team, are schema writes idempotent in SpiceDB? Yes, you can repeat a WriteSchema call with the same contents with no ill effects > If the write command is called, but there are no changes, will a new revision be created? Yes, but that's because all writes to the datastore result in a new revision; queries before/after the schema write will see the appropriate schema based on the revision selected for the query. > Also, any details on how multiple concurrent schema updates are handled? What happens if two (or even 10) schema writes happen simultaneously, do they get executed sequentially? Details depend on the datastore, but in general the writes are automatically serialized by the backing database (so you'll get an externally visible write order) or one write will fail and return to the client. There's no risk of interleaved schema writes, if that's the question. > It will make my deployment flow a lot easier if I can call write on every app deployment without having to check if there has been a change to the schema That works fine if your deployment flow is the only thing you expect to be writing schema. Otherwise doing this will overwrite schema changes from other sources.

Cool cool, thanks for clearifying Seems like I have to manage changes external to SpiceDB and only call write if there is a change unless I want the db to be filled up with empty revisions. Good to know

how often do you deploy those changes? Is it more often than writes to the system? Revisions are garbage collected every 24 hours. I'd be surprise that becomes a problem at all, and if you wanted to spare some bytes, you could configure revision GC on a shorter time window.

Oh! that makes it a moot point. I was mostly concerned with having a huger number of revisions sitting around after a year. My thinking was that if I do a couple of deployments per day, and the deployment pipeline updates the schema each time it will be a big number, but if they don't last for long, then no worries. I was on my way down a path of only running a step in the application deployment pipeline if the schema file has changed, but sounds like that is not a requirement. I've been through a few iterations of startups where cleaning up the data was a later problem, and suddenly everything ground to a halt and everyone was unhappy

yeah I don't think that would be a problem with just a few schema deployments per day. Even if you did one per second. Typical scenarios in production are way more than that - every relationship write adds a revision to the transactions table, so you can imagine the rate of revisions is proportional to your write throughput. That's is typically not an issue, and again, you can always tune the GC cadence and window if it ever became a problem.