The following limitations apply to Prisma Migrate.
MongoDB connector not supported
Prisma Migrate does not currently support the MongoDB connector.
You cannot automatically switch database providers
Prisma Migrate generates SQL files that are specific to your provider. This means that you cannot use the same migration files for PostgreSQL in production and SQLite in development, because the syntax in the migrations will be incompatible.
In 2.15.0 and later, Prisma Migrate detects when the migrations do not match the configured provider and prints a helpful error message. For example, if your migrations are for a PostgreSQL database but you are using a
provider is set to
Error: P3014The datasource provider `postgresql` specified in your schema does not match the one specified in the migration_lock.toml, mysql. Please remove your current migration directory and start a new migration history with prisma migrate dev.
In order to manually switch the database provider, you must:
- Change the
urlparameters in the
datasourceblock in your schema
- Archive or remove your existing migration history - there must not be a
prisma migrate devto start a new migration history
The last step creates a new initial migration that goes from an empty database to your current
schema.prisma. Be aware that:
- This migration will only contain what is reflected in your
schema.prisma. If you manually edited your previous migration files to add custom SQL you will need to again add this yourself.
- The newly created database using the new provider will not contain any data.
Data loss when resetting database
In a development environment, Prisma Migrate sometimes prompts you to reset the database. Resetting drops and recreates the database, which results in data loss. The database is reset when:
- You call
prisma migrate resetexplicitly
- You call
prisma migrate devand Prisma Migrate detects drift in the database or a migration history conflict
prisma migrate dev and
prisma migrate reset commands are designed to be used in development only, and should not affect production data.
When the database is reset, if Prisma Migrate detects a seed script in
package.json, it will trigger seeding.
Note: For a simple and integrated way to re-create data when the database is reset, check out our seeding guide.
Prisma Migrate and PgBouncer
You might see the following error if you attempt to run Prisma Migrate commands in an environment that uses PgBouncer for connection pooling:
Error: undefined: Database errorError querying the database: db error: ERROR: prepared statement "s0" already exists
See Prisma Migrate and PgBouncer workaround for further information and a workaround. Follow GitHub issue #6485 for updates.
Prisma Migrate in non-interactive environments
Prisma detects when you run CLI commands in non-interactive environments, such as Docker, from Node scripts or in bash shells. When this happens a warning displays, indicating that the environment is non-interactive and the
migrate dev command is not supported.
To ensure the Docker environment picks up the command, run the image in
interactive mode so that it reacts to the
migrate dev command.
$docker run --interactive --tty <image name>$# or$docker -it <image name>$$# Example usage$docker run -it node