I setup spicedb the first time, write the schema, write initial relationships with a script, keep relationships up to date with application logic, and do backups via zed?

otherwise yeah you can take backups with

zed backup

we keep our spicedb schema in the associated codebase and write the schema on app startup

what do you mean by "migration-like?"

migration-like: captured in repository, code-like source of truth of the changes over time, that can be applied to return to the current state

I don't anticipate schema updates in my project, but I also know better than to assume it will never happen.

In my usecase, such updates may need to be applied to instances that I don't exactly run, so I need to be able to vend the incremental change that should be applied to my clients

I can presumably handroll something in the application, but I like to check first that I'm not reinventing the wheel

but part of that is that a

WriteSchema

call is always the entire schema

so there's no notion of incremental updates

you could, say, remove a permission

and then checks would fail on it

but you can't have data inconsistency

our recommendation is to have a CI/CD process that uses

zed validate

or the equivalent GitHub Action to validate the schema + the assertions

and then have either an automatic or manual process to call

WriteSchema

down the road, we have plans for the ability to "stage" a schema change so you can do a progressive rollout

but that's the future

thanks :)