Writing Saleor migrations

Saleor deploys with zero downtime across many pods against a shared Postgres. A migration that takes a long table lock stalls every pod. Follow these rules.

Keep locks short: split migrations

• One model per migration, and one field change per migration. Each schema operation holds a lock on the table for its duration; batching several into one migration multiplies the locked time.
• The only valid reason to combine is separating a schema migration from its data migration.
• Always separate schema changes and data migration.
• Don't add a migration that re-alters a column an earlier migration already changed — check the existing migration history first.
• Give migrations descriptive names that reflect the actual operation (0070_add_payment_gift_card_brand, not 0070_alter_payment_partial_add_db_default for something else).

Indexes and constraints: create concurrently