Changing column types in Ruby on Rails - Performance & Optimization

Performance: Changing column types

MEDIUM IMPACT

This affects page load speed indirectly by impacting database query performance and server response time, which can delay rendering of data-driven pages.

Changing a database column type in a Rails migration

Ruby on Rails

class ChangeColumnTypeGood < ActiveRecord::Migration[7.0]
  def up
    add_column :users, :age_new, :string
    execute('UPDATE users SET age_new = age::text')
    remove_column :users, :age
    rename_column :users, :age_new, :age
  end

  def down
    # reverse steps
  end
end

This approach avoids locking the entire table by adding a new column and migrating data, reducing downtime.

📈 Performance Gainreduces blocking time to seconds, allowing faster page responses and better LCP

Changing a database column type in a Rails migration

Ruby on Rails

class ChangeColumnTypeBad < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :age, :string
  end
end

This runs a blocking operation that locks the entire table during migration, causing downtime and slow queries until complete.

📉 Performance Costblocks database writes for several seconds to minutes depending on table size, delaying page responses

Performance Comparison

Pattern	Database Locking	Query Speed	User Impact	Verdict
Direct change_column	Full table lock	Slow during migration	Page load delays, downtime	[X] Bad
Add new column + backfill	Minimal locking	Fast queries after migration	Minimal downtime, faster page loads	[OK] Good

Rendering Pipeline

Changing column types affects the backend database layer, which impacts how fast data queries return results. Slow queries delay server response, which delays browser receiving HTML and rendering content.

→Server Processing

→Network Transfer

→Rendering

⚠️ BottleneckServer Processing due to database locks and slow queries

Core Web Vital Affected

LCP

This affects page load speed indirectly by impacting database query performance and server response time, which can delay rendering of data-driven pages.

Optimization Tips

1Avoid direct column type changes on large tables to prevent long database locks.

2Use add-column and backfill strategy to minimize downtime and speed up queries.

3Monitor server response times during migrations to ensure good user experience.

Performance Quiz - 3 Questions

What is the main performance risk when changing a column type directly in a large Rails database table?

A The browser will re-render the page multiple times

B The table gets locked, causing slow queries and delayed page loads

C CSS styles will be recalculated unnecessarily

D JavaScript bundle size increases significantly

DevTools: Network

How to check: Open DevTools, go to Network tab, reload page and observe server response times for data requests.

What to look for: Look for long waiting (TTFB) times indicating slow server response due to database migration impact.

Practice

1.

What is the primary Rails method used to change the type of an existing database column in a migration?

easy

A. change_column

B. rename_column

C. add_column

D. remove_column

Solution

1. Step 1: Understand migration methods

   Rails migrations provide specific methods for altering tables. add_column adds new columns, remove_column deletes columns, and rename_column changes column names.

2. Step 2: Identify method for changing column type

   The method change_column is designed to change the type of an existing column without removing it.

3. Final Answer:

   change_column -> Option A

4. Quick Check:

   Change column type = change_column [OK]

Hint: Use change_column to modify column types in migrations [OK]

Common Mistakes:

• Confusing change_column with rename_column
• Trying to use add_column to change type
• Using remove_column instead of changing type

2.

Which of the following is the correct syntax to change a column named price to type decimal with precision 8 and scale 2 in a Rails migration?

class ChangePriceTypeInProducts < ActiveRecord::Migration[7.0]
  def change
    ?
  end
end

easy

A. change_column :products, :price, :decimal, precision: 8, scale: 2

B. change_column :products, :price, :decimal(8,2)

C. change_column :products, :price, :decimal, {precision: 8, scale: 2}

D. change_column :products, :price, :decimal, precision => 8, scale => 2

Solution

1. Step 1: Review change_column syntax

   The correct syntax uses symbol keys for options: change_column(table, column, type, options). Options like precision and scale are passed as keyword arguments.

2. Step 2: Identify correct option format

   change_column :products, :price, :decimal, precision: 8, scale: 2 correctly uses precision: 8, scale: 2 as keyword arguments. change_column :products, :price, :decimal(8,2) uses invalid syntax. change_column :products, :price, :decimal, {precision: 8, scale: 2} uses a hash but without keyword arguments. change_column :products, :price, :decimal, precision => 8, scale => 2 uses hash rockets which is invalid in this context.

3. Final Answer:

   change_column :products, :price, :decimal, precision: 8, scale: 2 -> Option A

4. Quick Check:

   Keyword args for options = change_column :products, :price, :decimal, precision: 8, scale: 2 [OK]

Hint: Use keyword arguments for options in change_column [OK]

Common Mistakes:

• Using parentheses in type declaration like :decimal(8,2)
• Passing options as a hash without keywords
• Using old hash rocket syntax in options

3.

Given this migration snippet, what will be the new type of the age column after running it?

class ChangeAgeTypeInUsers < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :age, :string
  end
end

medium

A. integer

B. boolean

C. string

D. float

Solution

1. Step 1: Read the change_column call

   The method call changes the age column in the users table to type :string.

2. Step 2: Understand the effect

   After running the migration, the age column will store string values instead of its previous type.

3. Final Answer:

   string -> Option C

4. Quick Check:

   change_column to :string = string [OK]

Hint: Look at the third argument of change_column for new type [OK]

Common Mistakes:

• Assuming the type stays the same
• Confusing column name with type
• Thinking change_column renames columns

4.

What is wrong with this migration code that tries to change a column type?

class ChangeActiveToBooleanInUsers < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :active, 'boolean'
  end
end

medium

A. The column name should be a string, not a symbol

B. The type should be a symbol, not a string

C. change_column cannot change to boolean type

D. The migration class name is invalid

Solution

1. Step 1: Check argument types in change_column

   The method expects the type argument as a symbol, e.g., :boolean, not a string.

2. Step 2: Identify the error

   Using a string like 'boolean' will cause a syntax or runtime error because Rails expects symbols for types.

3. Final Answer:

   The type should be a symbol, not a string -> Option B

4. Quick Check:

   Type argument must be symbol = The type should be a symbol, not a string [OK]

Hint: Use symbols (e.g., :boolean) for types in change_column [OK]

Common Mistakes:

• Passing type as a string instead of symbol
• Thinking change_column can't handle boolean
• Misnaming migration class

5.

You want to change a column rating from integer to decimal with precision 3 and scale 1, but keep existing data safe. Which approach is best?

hard

A. Use change_column :table, :rating, :decimal, precision: 3, scale: 1 directly in one migration

B. Change the column type in the database manually without migration

C. Drop the column and add a new decimal column with the same name

D. Create a new decimal column, copy data with conversion, then remove old column and rename new one

Solution

1. Step 1: Understand risks of direct change_column

   Directly changing column type can cause data loss or errors if existing data doesn't fit new type.

2. Step 2: Use safe migration strategy

   Creating a new column, copying data with conversion, then removing old column and renaming new one ensures data safety and rollback ability.

3. Final Answer:

   Create a new decimal column, copy data with conversion, then remove old column and rename new one -> Option D

4. Quick Check:

   Safe type change = create-copy-rename [OK]

Hint: Avoid direct type change; copy data safely first [OK]

Common Mistakes:

• Directly changing type risking data loss
• Dropping column without backup
• Changing DB manually without migration