Migration Guard

I have reviewed 20231027120000_add_not_null_to_users_email.rb. Adding a NOT NULL constraint to an existing column in PostgreSQL requires a full table scan while holding an SHARE UPDATE EXCLUSIVE lock, which will block writes on a large table.

Migration Risk Report

Analysis

PostgreSQL must verify that no null values exist before applying the constraint. On a large users table, this scan can take significant time. Because this migration runs in a transaction, it holds the lock for the duration of the scan, potentially causing a connection pile-up.

Safe Rewrite (Expand/Contract Pattern)

To deploy this safely, you should split this into three steps across two deployments.

Step 1: Add a Check Constraint (Invalid)
This adds the constraint without validating existing rows, avoiding the long lock.

class AddEmailNotNullConstraint < ActiveRecord::Migration[7.0]
  def change
    add_check_constraint :users, "email IS NOT NULL", name: "email_is_not_null", validate: false
  end
end

Step 2: Validate the Constraint
Run this in a separate migration. The scan is performed, but it does not block reads or writes.

class ValidateEmailNotNullConstraint < ActiveRecord::Migration[7.0]
  def change
    validate_check_constraint :users, name: "email_is_not_null"
  end
end

Step 3: Finalize (Optional)
Once validated, you can safely set the actual NOT NULL column property as it is now a metadata-only change.

Next steps

1. Replace the current migration with the "Step 1" code block.
2. Verify if there are any existing NULL values in the email column before running Step 2.
3. Apply a statement_timeout to your migration runner for added safety.