Database Migration

In Turkish: Veritabanı Migration'ı

Updated September 30, 20262 min read

In short

A database migration is a versioned script that changes a database's schema, such as adding a column, so every environment applies the same changes in order.

What is a database migration?

A database migration, also called a schema migration, is a small, versioned file that describes one change to a database's structure, such as creating a table, adding a column, or adding an index. Migrations are stored in the project's repository next to the application code and applied in order, so the database schema evolves step by step together with the code that depends on it.

A migration tool keeps a special table in the database that records which migrations have already run. When you deploy, the tool compares that list with the migration files and applies only the new ones, usually from a CI/CD pipeline or at application startup. Many migrations also include a down step that reverses the change. Common tools include Flyway and Liquibase, and frameworks and ORMs such as Django, Rails, Entity Framework, Prisma, and Drizzle have migration systems built in.

Think of migrations as version control for your database structure: just as Git lets every developer rebuild the same code from its history, migrations let every laptop, test server, and production database reach exactly the same schema. This replaces the risky habit of changing production tables by hand and forgetting to repeat the change everywhere else.

Migrations on live systems need care, because some changes lock large tables or break the version of the app that is still running. A common safe approach is the expand-and-contract pattern: add the new column first, deploy code that writes to both the old and new columns, backfill existing rows, and only later remove the old column. Note that database migration can also mean moving data from one database system to another, such as from MySQL to PostgreSQL, which is a separate kind of project.

Key takeaways

A migration is a versioned file describing one schema change.
Migrations are committed with the code and applied in a fixed order.
The tool records applied migrations so each one runs only once per database.
Down migrations can reverse a change when the tool supports them.
Use expand-and-contract steps to change live databases without downtime.

Example

A migration file with up and down stepssql

-- migrations/20260930120000_add_phone_to_users.sql

-- Up: apply the change
ALTER TABLE users ADD COLUMN phone TEXT;
CREATE INDEX idx_users_phone ON users (phone);

-- Down: undo the change
DROP INDEX idx_users_phone;
ALTER TABLE users DROP COLUMN phone;

Readers ask

What is the difference between a schema migration and a data migration?

A schema migration changes the structure of the database, such as tables, columns, and indexes. A data migration changes or moves the data itself, such as filling a new column or transferring records to a different database system.

Should I edit a migration after it has been applied?

No. Once a migration has run on a shared or production database, write a new migration for further changes, because editing the old file would leave existing databases out of sync with it.

Can database migrations be rolled back?

Many tools let you write a down migration that reverses the change, but some changes, like dropping a column, destroy data and can't truly be undone. In production, teams often prefer to roll forward with a new corrective migration.