Currently there is a class of database migration scripts that require a shutdown of the app server, sometimes (though rarely) for long periods of time. These are scripts that require an exclusive lock on one or more database tables in order to modify the schema or indexes. The need to shut down the app server creates a bottleneck that makes it difficult to run frequent upgrades.

For some changes we can easily migrate to the new schema in a way that doesn't require an exclusive table lock. For example, adding a new column with a NOT NULL constraint and a default value shouldn't require a table lock.

For other changes we need to get more creative. For example, here's one way of renaming a column:

• SQL: create a new column with the new name
• SQL: set up a trigger that copies changes to the old column to the new column
• SQL: copy all values from the old column to the new column (the trigger will take care of any future changes)
• [Deploy code that uses the new column]
• SQL:  remove the old column.

I don't have much experience with this type of work but I think I see one architectural change we'll need to make. These techniques effectively split a database migration into two parts: a "setup" migration that happens before the new code is deployed and a "cleanup" migration that happens afterwards. Currently we assume that a schema migration either happens or it doesn't.