We've got a desktop B2B application which we also run with per-tenant DB. This makes the setup equal between our hosted service and on-prem.
When updating, schema changes goes first and when successful the new version is allowed to be executed by users. We have small launcher app that the users run which starts the actual application to handle this.
Our DB changes are always backwards compatible in the sense that the old version should operate correctly on an updated DB.
Incompatible changes like renaming a column we handle by rolling out the new column first, then wait till the version still using the old column is retired before removing the column from the schema, or similar strategies.
This way partial updates are safe, as the old app will just continue to use the partially updated DB as normal.
We're migrating to a web app, and hope to have something similar. Plan is we'll update the tenant DB and once done we'll change the app routing so that new user sessions for that tenant goes to new app instances running the updated version.
When updating, schema changes goes first and when successful the new version is allowed to be executed by users. We have small launcher app that the users run which starts the actual application to handle this.
Our DB changes are always backwards compatible in the sense that the old version should operate correctly on an updated DB.
Incompatible changes like renaming a column we handle by rolling out the new column first, then wait till the version still using the old column is retired before removing the column from the schema, or similar strategies.
This way partial updates are safe, as the old app will just continue to use the partially updated DB as normal.
We're migrating to a web app, and hope to have something similar. Plan is we'll update the tenant DB and once done we'll change the app routing so that new user sessions for that tenant goes to new app instances running the updated version.
That said, we've not got 1 million users... yet.