Development and production
In a development environment, use the migrate dev command to generate and apply migrations:
bunx prisma migrate devpnpm prisma migrate devyarn prisma migrate devnpx prisma migrate devThis command:
- 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)
- Applies pending migrations to the shadow database (for example, new migrations created by colleagues)
- If it detects changes to the Prisma schema, it generates a new migration from these changes
- Applies all unapplied migrations to the development database and updates the
_prisma_migrationstable - 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 resetpnpm prisma migrate resetyarn prisma migrate resetnpx prisma migrate reset[!WARNING]
migrate resetis a development command and should never be used in a production environment.
This command:
- Drops the database/schema¹ if possible, or performs a soft reset if the environment does not allow deleting databases/schemas*
- Creates a new database/schema¹ with the same name if the database/schema¹ was dropped
- Applies all migrations
[!NOTE] For MySQL and MongoDB this refers to the database, for PostgreSQL and SQL Server to the schema, and for SQLite to the database file.
To re-create data in your development database as often as needed, run npx prisma db seed. See the seeding guide.
This command:
- Drops the database/schema¹ if possible, or performs a soft reset if the environment does not allow deleting databases/schemas*
- Creates a new database/schema¹ with the same name if the database/schema¹ was dropped
- Applies all migrations
To re-create data in your development database as often as needed, run npx prisma db seed. See the 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 aTag[] - 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 stored procedure or a trigger.
The --create-only command allows you to create a migration without applying it:
bunx prisma migrate dev --create-onlypnpm prisma migrate dev --create-onlyyarn prisma migrate dev --create-onlynpx prisma migrate dev --create-onlyTo 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 deploypnpm prisma migrate deployyarn prisma migrate deploynpx prisma migrate deploymigrate 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:
- Compares applied migrations against the migration history and warns if any migrations have been modified:
Bash WARNING The following migrations have been modified since they were applied: 20210313140442_favorite_colors - 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:
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:
-
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 -
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 makes use of advisory locking when you run production commands such as:
prisma migrate deployprisma migrate devprisma 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:
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