Migration creation in Laravel - Performance & Optimization

Performance: Migration creation

LOW IMPACT

Migration creation affects the initial database setup and schema changes, impacting backend response times during deployment but not directly the frontend page speed.

Creating database tables with migrations

Laravel

Schema::create('users', function (Blueprint $table) {
    $table->increments('id');
    $table->string('name');
    $table->string('email')->unique();
    $table->timestamps();
    $table->string('extra_column')->nullable();
    // All columns added in a single migration to minimize schema changes
});

Combining all schema changes in one migration reduces rebuilds and locks, speeding up deployment.

📈 Performance GainSingle schema rebuild and lock, reducing deployment time and backend downtime.

Creating database tables with migrations

Laravel

Schema::create('users', function (Blueprint $table) {
    $table->increments('id');
    $table->string('name');
    $table->string('email')->unique();
    $table->timestamps();
    // Adding multiple columns in separate migrations causing multiple schema rebuilds
});

Creating or modifying tables in multiple separate migrations causes repeated schema rebuilds and locks, slowing deployment.

📉 Performance CostTriggers multiple database schema rebuilds and locks, increasing deployment time by seconds to minutes depending on DB size.

Performance Comparison

Pattern	Database Operations	Locks	Deployment Time	Verdict
Multiple small migrations	Multiple schema rebuilds	Multiple locks	Longer deployment	[X] Bad
Single combined migration	Single schema rebuild	Single lock	Faster deployment	[OK] Good

Rendering Pipeline

Migration creation runs on the backend and does not directly affect browser rendering. However, inefficient migrations can delay backend readiness, indirectly affecting page load if the database is not ready.

→Backend Database Setup

→Deployment Process

⚠️ BottleneckDatabase schema rebuild and locking during migration execution

Optimization Tips

1Batch schema changes in as few migrations as possible.

2Avoid running multiple migrations that rebuild the same table repeatedly.

3Migration performance affects backend deployment time, not frontend rendering.

Performance Quiz - 3 Questions

What is a performance downside of creating many small migrations instead of one combined migration?

A It reduces database locking time.

B It causes multiple database schema rebuilds and locks, slowing deployment.

C It improves frontend page load speed.

D It decreases backend response time during normal app use.

DevTools: Network

How to check: Monitor backend API response times during deployment and database migration execution.

What to look for: Look for increased response times or timeouts indicating database locks or slow migrations.

Practice

1. What is the primary purpose of a migration in Laravel?

easy

A. To create and modify database tables in a structured way

B. To handle user authentication

C. To manage routes in the application

D. To compile CSS and JavaScript assets

Solution

1. Step 1: Understand migration role

   Migrations are designed to manage database schema changes safely and consistently.

2. Step 2: Compare with other options

   Options A, C, and D relate to authentication, routing, and asset compilation, which are not migration tasks.

3. Final Answer:

   To create and modify database tables in a structured way -> Option A

4. Quick Check:

   Migration = Manage database tables [OK]

Hint: Migrations always deal with database tables [OK]

Common Mistakes:

• Confusing migrations with routing or authentication
• Thinking migrations compile assets
• Assuming migrations handle user sessions

2. Which command correctly creates a new migration file in Laravel?

easy

A. php artisan migration:create users

B. php artisan make:migration create_users_table

C. php artisan new:migration users_table

D. php artisan create:migration users

Solution

1. Step 1: Recall Laravel migration command

   The correct command to create a migration is php artisan make:migration followed by the migration name.

2. Step 2: Check each option

   Only php artisan make:migration create_users_table uses the correct syntax and command name.

3. Final Answer:

   php artisan make:migration create_users_table -> Option B

4. Quick Check:

   Use 'make:migration' to create migrations [OK]

Hint: Use 'make:migration' command to create migrations [OK]

Common Mistakes:

• Using wrong artisan command names
• Omitting 'make:' prefix
• Confusing migration creation with other artisan commands

3. Given this migration snippet, what will happen when running php artisan migrate?

public function up()
{
    Schema::create('posts', function (Blueprint $table) {
        $table->id();
        $table->string('title');
        $table->text('content');
        $table->timestamps();
    });
}

medium

A. Updates the 'posts' table by adding new columns

B. Deletes the 'posts' table if it exists

C. Creates a 'posts' table with id, title, content, and timestamps columns

D. Throws an error because 'timestamps' is not a valid method

Solution

1. Step 1: Analyze the up() method

   The code uses Schema::create to make a new table named 'posts' with columns: id, title, content, and timestamps.

2. Step 2: Understand Laravel Schema methods

   $table->timestamps() adds created_at and updated_at columns automatically. This is valid and common.

3. Final Answer:

   Creates a 'posts' table with id, title, content, and timestamps columns -> Option C

4. Quick Check:

   Schema::create + columns = new table [OK]

Hint: Schema::create builds new tables with specified columns [OK]

Common Mistakes:

• Thinking timestamps() is invalid
• Confusing create with update
• Assuming it deletes tables

4. Identify the error in this migration code:

public function up()
{
    Schema::create('comments', function (Blueprint $table) {
        $table->increments('id');
        $table->string('text');
        $table->timestamps;
    });
}

medium

A. String column 'text' must have a length specified

B. Using increments instead of id method

C. Table name should be singular, not plural

D. Missing parentheses after timestamps method call

Solution

1. Step 1: Check method calls in migration

   $table->timestamps is missing parentheses. It should be $table->timestamps() to call the method.

2. Step 2: Validate other parts

   Using increments('id') is valid, plural table names are allowed, and string columns default length is 255 if not specified.

3. Final Answer:

   Missing parentheses after timestamps method call -> Option D

4. Quick Check:

   Method calls need parentheses () [OK]

Hint: Always add () when calling migration methods [OK]

Common Mistakes:

• Forgetting parentheses on method calls
• Thinking increments is invalid
• Believing table names must be singular

5. You want to create a migration that adds a nullable 'bio' text column to the existing 'users' table. Which up() method code is correct?

hard

A. Schema::table('users', function (Blueprint $table) {
$table->text('bio')->nullable();
});

B. Schema::create('users', function (Blueprint $table) {
$table->text('bio')->nullable();
});

C. Schema::modify('users', function (Blueprint $table) {
$table->text('bio')->nullable();
});

D. Schema::addColumn('users', 'bio', 'text')->nullable();

Solution

1. Step 1: Understand how to modify existing tables

   To add a column to an existing table, use Schema::table with a closure defining the new column.

2. Step 2: Evaluate each option

   Schema::table('users', function (Blueprint $table) { $table->text('bio')->nullable(); }); correctly uses Schema::table and adds a nullable text column. Schema::create('users', function (Blueprint $table) { $table->text('bio')->nullable(); }); tries to create a new table, which is wrong. Options A and D use invalid Schema methods.

3. Final Answer:

   Schema::table('users', function (Blueprint $table) { $table->text('bio')->nullable(); }); -> Option A

4. Quick Check:

   Use Schema::table to add columns [OK]

Hint: Use Schema::table to change existing tables [OK]

Common Mistakes:

• Using Schema::create instead of Schema::table
• Using non-existent Schema methods
• Forgetting nullable() for optional columns