any documentation available for this

SpiceDB will validate the schema your client attempts to write, and identify any potential change that could cause data loss and return an error. You won't be able to write an "incompatible" schema. The most common scenario is removing/changing a relation that has data to it. When it comes to schema evolution, we have a blog post that talks about it: https://authzed.com/blog/online-schema-migrations/ SpiceDB schema migrations have similarities to database migrations, in that the same strategies are applicable (https://engineering.ezcater.com/migrate-transform-and-backfill-data-with-zero-downtime). These things cannot be done atomically at scale without downtime. So some schema migrations also involve a data migration. In the case of the latter, that's rarely automatable as it is specific to your business domain. Schema migrations are also known to be difficult to scale - see companies like Planetscale having key product offerings like "database branching model" to make schema migrations easier. If you are introducing a breaking schema change in your SpiceDB schema, you need to plan the classical multi-phase migration to do it with no downtime: - add new objects and relations to schema, keep old ones - start writing relationships to new relations along old relations (a.k.a "dual-write") - run backfill job (copy data from old relations to new relations) - update permissions to start using new data or even create new permissions (the latter allows you to switch back your client app in case something is not working as intended) - stop writing to old relations - delete old relationships - remove old relations and objects from schema (edited)