Prisma Migrate

Do not edit or delete migrations that have been applied

In general, you should not edit or delete a migration that has already been applied. Doing so can lead to inconsistencies between development and production environment migration histories, which may have unforeseen consequences - even if the change does not appear to break anything at first.

The following scenario simulates a change that creates a seemingly harmless inconsistency:

1. Modify an existing migration that has already been applied in a development environment by changing the value of VARCHAR(550) to VARCHAR(560):

   ./prisma/migrations/20210310143435_default_value/migrations.sql
   1  -- AlterTable
   2 ALTER TABLE "Post" ALTER COLUMN "content" SET DATA TYPE VARCHAR(560);

   After making this change, the end state of the migration history no longer matches the Prisma schema, which still has @db.VarChar(550).

2. Run prisma migrate dev - Prisma Migrate detects that a migration has changed, and asks to reset the database:

   ? The migration `20210310143435_change_type` was modified after it was applied.
   
    We need to reset the PostgreSQL database "migrate-example" at "localhost:5432".
    Do you want to continue? All data will be lost. » (y/N)

3. If you accept resetting, Prisma Migrate resets the database and replays all migrations, including the migration you edited.

4. After applying all existing migrations, Prisma Migrate compares the end state of the migration history to the Prisma schema and detects a discrepancy:

   • Prisma schema has @db.VarChar(550)
   • Database schema has VARCHAR(560)

5. Prisma Migrate generates a new migration to change the value back to 550, because the end state of the migration history should match the Prisma schema.

6. From now on, when you use prisma migrate deploy to deploy migrations to production and test environments, Prisma Migrate will always warn you that migration histories do not match (and continue to warn you each time you run the command ) - even though the schema end states match:

6 migrations found in prisma/migrations
WARNING The following migrations have been modified since they were applied:
20210310143435_change_type

A change that does not appear to break anything after a migrate reset can hide problems - you may end up with a bug in production that you cannot replicate in development, or the other way around - particularly if the change concerns a highly customized migration.

If Prisma Migrate reports a missing or edited migration that has already been applied, we recommend fixing the root cause (restoring the file or reverting the change) rather than resetting.

Source-controlling the migration history

You must commit the entire prisma/migrations folder to source control. This includes the prisma/migrations/migration_lock.toml file, which is used to detect if you have attempted to change providers.

Source-controlling the schema.prisma file is not enough - you must include your migration history. This is because:

• As you start to customize migrations, your migration history contains information that cannot be represented in the Prisma schema. For example, you can customize a migration to mitigate data loss that would be caused by a breaking change.
• The prisma migrate deploy command, which is used to deploy changes to staging, testing, and production environments, only runs migration files. It does not use the Prisma schema file to fetch the models.

Create and apply migrations

This command:

1. Replays 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. Generates a new migration from any changes you made to the Prisma schema before running migrate dev
4. Applies all unapplied migrations to the development database and updates the _prisma_migrations table
5. Triggers the generation of artifacts (for example, the 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:

$npx prisma migrate reset

Reset the development database

This command:

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

Note: For a simple and integrated way to re-create data in your development database as often as needed, check out our seeding guide.

Customizing migrations

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:

$npx prisma migrate dev --create-only

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

Refer to Customizing migrations for examples.

Team development

See: Team development with Prisma Migrate .

Advisory locking

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

• prisma migrate deploy
• 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.