Applications that use a database to store their state are bound to a specific database schema. Changes in the schema usually require the application model to change and vice versa. With an application being actively developed and a domain model being continuously refined and refactored, the model will eventually require the database schema to change. New model classes or properties thereof which are added need to be persisted in the database as well. Classes and properties that are refactored or removed should be migrated in the database also, so that the schema doesn't diverge.

However, data migrations are more difficult than code changes. Stateless applications can simply be replaced by new versions thereof, containing the new functionality. A database that contains the application's state, however, needs to carefully migrate the state when the schema changes.

This happens in migration scripts. Relational databases support altering their tables while keeping the data intact. These scripts are executed before the new version of the software is deployed, making sure the database schema matches the application.

There is an important aspect to keep in mind when deploying applications using a zero-downtime approach. Rolling updates will leave at least one active instance running in the environment at a time. This results in having both the old and the new software version active for a short period of time. The orchestration should take care that the applications are gracefully started and shut down, respectively, letting in-flight requests finish their work. Applications that connect to a central database instance will result in several versions of the application simultaneously accessing the database. This requires the application to support so-called N-1 compatibility. The current application version needs to function with the same database schema version plus and minus one version, respectively.

To support N-1 compatibility, the rolling update approach needs to both deploy a new application version and to updates the database schema, making sure the versions do not differ more than one version. This implies that, the corresponding database migrations are executed just before the application deployment takes place. The database schema, as well as the application, therefore evolves in small migration steps, not in jumps.

This approach, however, is not trivial and involves certain planning and caution. Especially, application version rollbacks require particular attention.