Prisma Migrations

Migrations are the version history of a database schema. Prisma Migrate compares schema.prisma to the previous migration state, generates SQL, and applies it in order. Treat generated SQL as code: review it before production sees it.

Local Development

prisma migrate dev creates a migration folder, writes SQL, applies it to the local database, and can rerun seed scripts. The generated migration file should be committed.

type MigrationCommand = {
  command: string;
  environment: "local" | "ci" | "production";
  purpose: string;
};

export const prismaMigrationCommands: MigrationCommand[] = [
  {
    command: "prisma migrate dev",
    environment: "local",
    purpose: "Create and apply a new migration interactively.",
  },
  {
    command: "prisma migrate deploy",
    environment: "production",
    purpose: "Apply pending committed migrations without prompts.",
  },
];

Deployment

Use prisma migrate deploy in CI/CD or release jobs. It applies pending migrations and avoids interactive prompts, which makes it suitable for automated production workflows. Do not run migrate dev in production.

Destructive Changes

Renaming a column can look like drop-and-create to migration tooling. That loses data unless you handle it deliberately. Use a multi-step migration: add the new column, backfill values, deploy code that reads the new column, then drop the old column later.

type SafeRenamePlan = [
  "add_new_column",
  "backfill_data",
  "deploy_code_using_new_column",
  "drop_old_column",
];

export const safeRenamePlan: SafeRenamePlan = [
  "add_new_column",
  "backfill_data",
  "deploy_code_using_new_column",
  "drop_old_column",
];

prisma db push is useful for rapid prototypes because it syncs schema without migration files. Avoid it for shared environments where you need reviewable, repeatable history.

Further Learning

Search these terms to go deeper:

• “Prisma migrate dev workflow” — local migration generation and seeding
• “Prisma migrate deploy production” — applying migrations in CI/CD
• “zero downtime database migration column rename” — safe destructive change patterns
• “Prisma migrate resolve drift” — repairing migration history mismatches

Prisma Migrations

When your data model changes (new field, renamed column), you need a repeatable way to apply that change to every environment — your laptop, staging, production. A migration is a saved, ordered record of exactly what changed, so nothing ever gets out of sync.

Making a change locally

prisma migrate dev

This looks at your schema, figures out what changed, writes the SQL for it, and applies it to your local database. It saves that SQL as a file you commit to Git — that file is your database’s version history.

Applying it in production

prisma migrate deploy

This runs the already-created migrations without asking any questions — perfect for automated deployment pipelines. Use migrate dev only locally; use migrate deploy in production.

The tricky part: renaming a column

If you just rename a column, migration tools can sometimes interpret that as “delete the old one, add a new empty one” — which loses all the data in it! The safe way is to do it in steps:

1. Add the new column.
2. Copy the data over (backfill).
3. Update your code to use the new column.
4. Later, once you’re sure it’s safe, drop the old column.

For quick prototyping

prisma db push skips the migration files entirely and just syncs your schema directly — handy for early experimentation, but skip it for any shared/production database since it leaves no history.

In one sentence

Migrations are a tracked, ordered history of schema changes — use migrate dev locally (commit the generated SQL) and migrate deploy in production, and handle risky changes like renames in safe multi-step stages so you never silently lose data.

Want to go deeper?

Switch to Expert mode above for the full safe-rename plan and db push trade-offs.