Hi While upgrading spicedb if we face any issue with upgraded version, any documentation on how can we revert to older version of spicedb. Thanks

there is no documentation of reverts. Which version are you at and what do you want to revert to?

We are analysing the revert options, because we are upgrading from v1.2.0 to latest manually. Our data store is postgres and we want to figure-out the rollback strategy beforehand if happen unexpected how fast can we revert to previous version. We are running spicedb in kubernetes as a stand alone deployment along with our application.

You can rollback SpiceDB, so long it's not a 4-phase migration. If there is a 4-phase migration, there is no way back, because the process the data model will be changed in an incompatible way. Postgres datastore has at least one 4-phase migration that takes place in version v1.14, so that'd be the sensitive one. Here is a list of all the database migrations in the postgres datastore: https://github.com/authzed/spicedb-operator/blob/main/validated-update-graph.yaml#L255-L353

Thanks @vroldanbet

That is correct, but perhaps to further clarify: it migrates to the latest datastore version of current spicedb version. So if you run

spicedb migrate head

with SpiceDB 1.13, it will migrate to the latest schema of that version.

Got it

my recommendation would be to bite the bullet and migrate to the

spicedb-operator

instead of keeping your own deployment. That way migrations will be handled automatically for you next time.

With kubernetes-operator can we control the version upto which we want to update. Reason for asking this we don't want to jump from v1.2.0 to latest in single go our service manages auth and permission for multiple teams and we can't handle any downtime on this. And if we use kubernetes operator any kind of fault toleration is there? Also if there is any change on the API side and our service stuck because of that it can be a huge impact for us.

yes you can control the version

Great, let us evaluate this also. > cluster has issues while rolling We are just running single container of spicedb as a separate deployment along with our application deployment I hope that is not an issue. We just need to deploy the spicedb operator in the same namespace and pin the version upto which we want to upgrade. Correct?

>We are just running single container of spicedb as a separate deployment along with our application deployment I hope that is not an issue. I don't see anything in this setup that would be an issue, it's the usual deployment model for SpiceDB. It's just a regular deployment using SpiceDB right? not injecting it as sidecar or anything like that? and you have more than 1 replicas I assume >We just need to deploy the spicedb operator in the same namespace and pin the version upto which we want to upgrade. Correct? IT does not have to be in the same namespace, unless you don't want to be doing cluster roles. I'd strongly recommend you run this whole procedure in an staging environment first, so you do a trial run of the various steps. The SpiceDB-Operator will create its own SpiceDB Deployment after your apply

SpiceDBCluster

custom resource to your kube cluster. Ideally you pin it to the same version you are currently running,

1.2.0

, and point it to the same database as your SpiceDB deployment. Once you know it's healthy and working, you would switch your client application to use the new spicedb-operator created

Deployment

, and delete the old adhoc

Deployment

. Now you can start upgrading via the operator.

>It's just a regular deployment using SpiceDB right? yes

@Manish 👋 it would be fine to scale to zero and run the migration. However, the issue with this migration is that it's a data migration, so the duration of the downtime is heavily dependent on the amount of data stored in your postgres - it has to go over all the rows in the database and perform a transformation over them. It may not be a "short" downtime, it could take from several minutes to even hours depending on the amount of data you stored.

Sure thanks

I can say that version 1.14 does require version 14 at least. I don't have reasons to believe it wouldn't work with 15, specially since we made it a requirement later on.

Okay we will test and update it here for others.