Additive Schema Updates vs. Multi-Phase Migrations for Rollback Safety

SpiceDB manages permissions through a global schema applied via the Schema API. When updating relationship types or permissions, there is a trade-off between immediate schema modification and a staged migration approach to ensure application rollback safety.

Additive changes allow the application to transition to new logic while maintaining compatibility with previous versions. However, destructive changes—such as renaming or deleting relationship types—create immediate inconsistencies if the application code is rolled back to a version expecting the previous schema definitions.

Given that removing a relationship type from the schema does not automatically purge existing tuples from the database, the strategy for maintaining data integrity during a rollback remains a design decision.

• Does an additive-only approach provide sufficient safety for complex permission refactoring?
• What is the recommended mechanism for handling orphaned tuples when transitioning from a multi-phase migration back to a previous schema state?