I was wondering if you guys have written
# spicedbw
WT
09/26/2025, 3:12 PMI was wondering if you guys have written/recommend any particular migration tooling for schema changes - we've rolled one in house, but would prefer to go with something more official if it exists
y
yetitwo
09/26/2025, 3:29 PMyou're talking about the four-phase approach that you'd need to take with a breaking schema change?
we don't currently have anything like that, though you're not the first person to ask about it.
yetitwo
09/26/2025, 3:33 PMis the idea that this tool would automatically delete relationships associated with relations that have been removed from the schema?
w
WT
09/26/2025, 6:26 PMYes, for sure - but I also mean more general tooling. I'd like a nice way to add new definitions, update/add/remove permissions + relationships.
We've worked with alembic a lot, and our tooling is modelled after that - ie. upgrade, downgrade and ops to modify state
WT
09/26/2025, 6:29 PMI'd be happy ultimately if there weren't any functions that automatically deal with breaking schema changes - just ones that efficiently capture schema changes ie. schema.rename("my_definition", "previous_relation_name", "new_relation_name")
y
yetitwo
09/26/2025, 7:04 PMis the idea that this would work on the schema that's written?
i agree that this would make sense for a schema that could be modified incrementally, such as postgres DDL, but a SpiceDB schema is written and considered atomically.
or is the idea that you'd have some handle on the text schema where you could call functions and modify an internal representation of the schema that would then be written out to a string?
w
WT
09/26/2025, 7:05 PMThe latter
WT
09/26/2025, 7:05 PMThat's how our internal lib works
WT
09/26/2025, 7:07 PMBut also ideally allowed data modification as well
y
yetitwo
09/26/2025, 8:57 PMinteresting. would it be useful if it were in the CLI, or would it only make sense to you if it was implemented in a client library in the language you use?
i think we've shied away from data modification because we'd rather that an incorrect destructive operation fails loudly and that a human be involved in the chain.
3 Views