| Table of Contents |
|---|
...
When using AWS Aurora, a nullable column can be added to existing large (100k rows+?) tables without causing downtime. However, the migration may still timeout in GoCD - so please coordinate the release with DevOps.
- Make a new field addition in model with null=True.
- Generate the model-change migrations locally.
- Create a pull request containing the model change and newly-generated migrations.
- Merge the migration pull request.
- The release process will run the migration and add the nullable column to table.
...
On AWS Aurora, indexes can be build on large tables without causing downtime, but this requires devops coordination as the migration may timeout in GoCD.
- Add the new index on model fields.
- Generate the model-change migrations locally.
- Make pull request containing the model change and newly-generated migrations.
- Merge the migration pull request.
- Release will run the migration and add the index to table.
Consider Making a New Model with a OneToOneField
Adding fields to large tables can cause operational issues. What is safe varies from database version (MySQL 5.7 vs. 5.8. vs. 8.0) and specialized backends (like Aurora). Also, even if the database supports adding things in a non-locking way, Django's migrations framework may not understand how to formulate the right SQL to do so.
A lower risk alternative is to create a new model and link it together with a OneToOneField. You can use the primary_key=True option in order to have the new table's primary key match the values of the parent table.
This does complicate the code somewhat, and you should be careful about avoiding n+1 queries by calling select_related. The benefit is not having to hold your breath when the migration rolls out, for fear that you just froze a heavily used table and brought down the site.
Mathematical perspective: Database Expansion/Contraction
...