# Development and production (Prisma ORM v7) (/docs/orm/v7/prisma-migrate/workflows/development-and-production)

> For the complete Prisma documentation index, see [llms.txt](https://www.prisma.io/docs/llms.txt). A markdown version of any docs page is available by appending `.md` to its URL.

How to use Prisma Migrate commands in development and production environments

Location: ORM > v7 > Prisma Migrate > Workflows > Development and production

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

  

#### bun

```bash
bunx prisma migrate dev
```

#### pnpm

```bash
pnpm prisma migrate dev
```

#### yarn

```bash
yarn prisma migrate dev
```

#### npm

```bash
npx prisma migrate dev
```

### Create and apply migrations [#create-and-apply-migrations]

> [!CAUTION]
> `migrate dev` is a development command and should never be used in a production environment.

This command:

* Reruns the existing migration history in the [shadow database](https://www.prisma.io/docs/orm/v7/prisma-migrate/understanding-prisma-migrate/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_migrations` table
* 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](https://www.prisma.io/docs/orm/v7/prisma-migrate/understanding-prisma-migrate/migration-histories#do-not-edit-or-delete-migrations-that-have-been-applied)
* The database schema has drifted away from the end-state of the migration history

### Reset the development database [#reset-the-development-database]

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

  

#### bun

```bash
bunx prisma migrate reset
```

#### pnpm

```bash
pnpm prisma migrate reset
```

#### yarn

```bash
yarn prisma migrate reset
```

#### npm

```bash
npx prisma migrate reset
```

> [!WARNING]
> `migrate reset` is 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](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/seeding).

### Customizing migrations [#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](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/customizing-migrations#example-rename-a-field) (by default, Prisma Migrate will drop the existing field)
* You want to [change the direction of a 1-1 relationship](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/customizing-migrations#example-change-the-direction-of-a-1-1-relation)
* 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:

  

#### bun

```bash
bunx prisma migrate dev --create-only
```

#### pnpm

```bash
pnpm prisma migrate dev --create-only
```

#### yarn

```bash
yarn prisma migrate dev --create-only
```

#### npm

```bash
npx prisma migrate dev --create-only
```

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

Refer to [Customizing migrations](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/customizing-migrations) for examples.

### Team development [#team-development]

See: [Team development with Prisma Migrate](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/development-and-production) .

## Production and testing environments [#production-and-testing-environments]

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

  

#### bun

```bash
bunx prisma migrate deploy
```

#### pnpm

```bash
pnpm prisma migrate deploy
```

#### yarn

```bash
yarn prisma migrate deploy
```

#### npm

```bash
npx prisma migrate deploy
```

`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:

  ```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:

* [Prisma Migrate in deployment](https://www.prisma.io/docs/orm/v7/prisma-client/deployment/deploy-database-changes-with-prisma-migrate)
* [Production troubleshooting](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/patching-and-hotfixing)

### Advisory locking [#advisory-locking]

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](https://www.postgresql.org/docs/9.4/explicit-locking.html#ADVISORY-LOCKS)
* [MySQL](https://dev.mysql.com/doc/refman/5.7/en/locking-functions.html)
* [Microsoft SQL server](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-getapplock-transact-sql?view=sql-server-ver15)

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](https://www.prisma.io/docs/orm/v7/reference/environment-variables-reference#prisma_schema_disable_advisory_lock)

## Related pages

- [`Baselining a database`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/baselining): How to initialize a migration history for an existing database that contains important data.
- [`Customizing migrations`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/customizing-migrations): How to edit a migration file before applying it to avoid data loss in production.
- [`Generating down migrations`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/generating-down-migrations): How to generate a down migration SQL file that reverses a given migration file
- [`Native database functions`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/native-database-functions): How to enable PostgreSQL native database functions for projects that use Prisma Migrate.
- [`Native database types`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/native-database-types): Native database types