When working in a high-risk environment, or with a fragile database, there is also another approach to database schema changes that can be taken. This approach is based on applying feature toggles and the blue–green deployment pattern, and goes as follows:

1. Change the application code in such a way that it writes any update to not just one, but to two databases.
2. In the production environment, create a complete, full copy of the existing database and configure the application code to write all changes to both databases. These databases will be called old and new, from now on.
3. Introduce the required changes to the new database schema and the application code only in the path that writes to the new database.
4. Introduce the necessary changes in all code paths that read data in such a way that all queries run against both databases.
5. Update the application code to detect differences in the query results between the new and the old databases, and log an error when it finds any discrepancy.
6. If the changes run without any issues, remove the old database, and the old read and write access paths, from the application code.
7. If the changes run with errors, fix the issue. Next, restart by restoring the backup of the intended new database, and resume at step five.

The advantage of this approach is that it is very lightweight. The downside is that it is very involved, takes a lot of work, and is more expensive. Also, the extra database costs and duration of backup and restore operations should be taken into account.