Definition
A database migration is a structured, version-controlled change to your database’s structure — its tables, columns, indexes, and relationships. Instead of manually modifying the database through a visual interface, developers write migration files that describe the change in code: “add a column called discount_percentage to the orders table” or “create a new table called subscriptions.” These migration files are committed to the repository alongside the application code, and they can be run forward to apply changes or rolled back to reverse them. Each migration is timestamped, so they are always applied in the correct order.
Why It Matters
Database migrations bring the same discipline to your database that version control brings to your code. Without them, database changes are manual, undocumented, and difficult to replicate — a developer makes a change on the staging server, forgets to apply it to production, and the deployment breaks. With migrations, every database change is recorded, reviewable, and repeatable. Every environment — development, staging, production — can be brought to the exact same state by running the same set of migrations. They also make rollbacks possible: if a migration causes a problem, it can be reversed in a controlled way rather than requiring someone to manually undo changes under pressure.
Example
Your development team is adding a loyalty points feature. The migration creates a new points_balance column on the customers table and a new table for tracking point transactions. The migration is reviewed as part of the pull request, tested on staging, and then applied to production during deployment. A week later, the business decides to also track point expiry dates. A new migration adds an expires_at column to the transactions table. The full history of how the database evolved is preserved in the migration files, making it easy for any developer to understand the current structure and how it got there.