Development and production

This page explains how to use Prisma Migrate commands in development and production environments.

In a development environment, use the migrate dev command to generate and apply migrations:

bunx prisma migrate dev

pnpm prisma migrate dev

yarn prisma migrate dev

npx prisma migrate dev

This command:

1. Reruns the existing migration history in the shadow database in order to detect schema drift (edited or deleted migration file, or a manual changes to the database schema)
2. Applies pending migrations to the shadow database (for example, new migrations created by colleagues)
3. If it detects changes to the Prisma schema, it generates a new migration from these changes
4. Applies all unapplied migrations to the development database and updates the _prisma_migrations table
5. Triggers the generation of artifacts (for example, Prisma Client)

The migrate dev command will prompt you to reset the database in the following scenarios:

• Migration history conflicts caused by modified or missing migrations
• The database schema has drifted away from the end-state of the migration history

You can also reset the database yourself to undo manual changes or db push experiments by running:

bunx prisma migrate reset

pnpm prisma migrate reset

yarn prisma migrate reset

npx prisma migrate reset

This command:

1. Drops the database/schema¹ if possible, or performs a soft reset if the environment does not allow deleting databases/schemas¹
2. Creates a new database/schema¹ with the same name if the database/schema¹ was dropped
3. Applies all migrations
4. Runs seed scripts

¹ For MySQL and MongoDB this refers to the database, for PostgreSQL and SQL Server to the schema, and for SQLite to the database file.

Note: To re-create data in your development database whenever it is reset, see our seeding guide.

Sometimes, you need to modify a migration before applying it. For example:

• You want to introduce a significant refactor, such as changing blog post tags from a String[] to a Tag[]
• You want to rename a field (by default, Prisma Migrate will drop the existing field)
• You want to change the direction of a 1-1 relationship
• You want to add features that cannot be represented in Prisma Schema Language - such as a partial index or a stored procedure.

The --create-only command allows you to create a migration without applying it:

bunx prisma migrate dev --create-only

pnpm prisma migrate dev --create-only

yarn prisma migrate dev --create-only

npx prisma migrate dev --create-only

To apply the edited migration, run prisma migrate dev again.

Refer to Customizing migrations for examples.

See: Team development with Prisma Migrate .

In production and testing environments, use the migrate deploy command to apply migrations:

bunx prisma migrate deploy

pnpm prisma migrate deploy

yarn prisma migrate deploy

npx prisma migrate deploy

Note: migrate deploy should generally be part of an automated CI/CD pipeline, and we do not recommend running this command locally to deploy changes to a production database.

This command:

1. Compares applied migrations against the migration history and warns if any migrations have been modified:

   WARNING The following migrations have been modified since they were applied:
   
   20210313140442_favorite_colors

2. Applies pending migrations

The migrate deploy command:

• Does not issue a warning if an already applied migration is missing from migration history
• Does not detect drift (production database schema differs from migration history end state - for example, due to a hotfix)
• Does not reset the database or generate artifacts (such as Prisma Client)
• Does not rely on a shadow database

See also:

• Prisma Migrate in deployment
• Production troubleshooting

Prisma Migrate makes use of advisory locking when you run production commands such as:

• prisma migrate deploy
• prisma migrate dev
• prisma migrate resolve

This safeguard ensures that multiple commands cannot run at the same time - for example, if you merge two pull requests in quick succession.

Advisory locking has a 10 second timeout (not configurable), and uses the default advisory locking mechanism available in the underlying provider:

• PostgreSQL
• MySQL
• Microsoft SQL server

Prisma Migrate's implementation of advisory locking is purely to avoid catastrophic errors - if your command times out, you will need to run it again.

Since 5.3.0, the advisory locking can be disabled using the PRISMA_SCHEMA_DISABLE_ADVISORY_LOCK environment variable