How to organize a zerodowntime update of the DBMS?

Question

Database

Such a question, how an "invisible" client update is implemented, has long been known, but how to implement it for a DBMS, I will give an example.
We have an application in any popular language / framework, we have assembled a container, put all the necessary packages into it and prepared everything, then the old version is still working, the new one is being prepared, and here the question arises. And what about the DBMS? If you start updating migrations (for example) to the current database, then the client will receive the 503rd and the whole point is lost. If you do a master standby and roll migrations on standby, then persistence is lost ... Who faced such a problem?

Answer 1

You must develop and deploy the application accordingly. So that the old version of the application can work with the new version of the database schema. Or vice versa, the new version of the application could work with the old database schema.
That is, deleting a table: first deploy an application that no longer works with this table, then delete the table
New table: first migration, then application
New field in the table with default value: first field, then application
New field without default: first, a new field with default null, then the release of the application, which is required to write a new field, but not yet read it (or cast null to the required one if it is possible on the application), then migration with the required value (and, damn it, not one update for the entire large table), drop default, set not null, deploy the application with all the logic
, and so on. During development, we think about how, when and in how many iterations it can be deployed.
And, of course, the DBA (or the person replacing it) thinks about how exactly to make the necessary migration into the database