How to fix P3019: The datasource provider specified in your schema does not match the one specified in the migration_lock.toml in Prisma

PrismaINTERMEDIATEHIGHUpdated Dec 25, 2025· 139 views

This error occurs when the database provider in your Prisma schema differs from the provider recorded in migration_lock.toml. It prevents applying migrations created for a different database system.

Quick fix

Fixes P3019

// prisma/schema.prisma
datasource db {
  provider = "postgresql"  // or "mysql", "sqlite", etc.
  url      = env("DATABASE_URL")
}
  1. Verify the provider mismatch
  2. Decide on the correct database provider
  3. Option 1: Revert to the original provider (no data loss)
  4. Option 2: Switch providers and reset migration history
prisma — error
// prisma/schema.prisma
datasource db {
  provider = "postgresql"  // or "mysql", "sqlite", etc.
  url      = env("DATABASE_URL")
}
P3019: The datasource provider specified in your schema does not match the one specified in the migration_lock.toml

What this error means

Starting with Prisma version 2.16, Prisma Migrate creates a migration_lock.toml file in your migrations directory that records which database provider (postgresql, mysql, sqlite, etc.) your migrations were generated for. This file acts as a safeguard to prevent migrations created for one database system from being accidentally applied to a different one. When you encounter error P3019, it means Prisma has detected that the provider field in your datasource block in schema.prisma doesn't match the provider recorded in the migration_lock.toml file. For example, your migrations might have been created for PostgreSQL, but your schema is now configured to use MySQL or SQLite. This mismatch check is intentional because database migrations are provider-specific—SQL syntax, data types, and constraints vary between database systems. Applying migrations meant for one provider to a different database could result in failed migrations, corrupted data, or subtle bugs.

Typical symptoms

  • Migration commands fail with "The datasource provider `X` specified in your schema does not match the one specified in the migration_lock.toml, `Y`"
  • Error occurs when running `prisma migrate deploy` or `prisma migrate dev`
  • Happens after switching database providers in schema.prisma
  • Appears when cloning a project and using a different database than the original
  • Migration history appears incompatible with current database configuration

Common causes

  1. Changed the provider in schema.prisma datasource block (e.g., from postgresql to mysql) without resetting migration history
  2. Using migrations created in a different environment with a different database provider
  3. Cloned a repository and configured a different database provider than the original project
  4. Accidentally committed migration_lock.toml with the wrong provider for your setup
  5. Attempting to use the same migration history across multiple database types
  6. Restored an old migration folder that was created for a different database provider

How to fix "P3019: The datasource provider specified in your schema does not match the one specified in the migration_lock.toml"

1Verify the provider mismatch

Check your current schema.prisma configuration:

prisma
// prisma/schema.prisma
datasource db {
  provider = "postgresql"  // or "mysql", "sqlite", etc.
  url      = env("DATABASE_URL")
}

Then check the migration_lock.toml file:

bash
cat prisma/migrations/migration_lock.toml

You'll see output like:

toml
# Please do not edit this file manually
# It should be added in your version-control system (i.e. Git)
provider = "sqlite"

If the provider values don't match, that's the source of your error.

2Decide on the correct database provider

Determine which database provider you actually want to use. Consider:

- Development vs Production: Are you using different databases in different environments?
- Team Standards: What provider is your team standardized on?
- Migration History: Do you need to preserve existing migrations?

If you're switching providers intentionally, be aware that you'll need to reset your migration history. If this was accidental, revert to the correct provider in your schema.

3Option 1: Revert to the original provider (no data loss)

If you accidentally changed the provider and want to go back:

1. Update your schema.prisma to match migration_lock.toml:

prisma
datasource db {
  provider = "postgresql"  // Match what's in migration_lock.toml
  url      = env("DATABASE_URL")
}

2. Update your DATABASE_URL environment variable to point to the correct database type.

3. Run migrations:

bash
npx prisma migrate deploy

This approach preserves your migration history and data.

4Option 2: Switch providers and reset migration history

If you genuinely need to switch to a different database provider:

1. Backup your data if you have any important data in your current database.

2. Delete the migrations folder:

bash
rm -rf prisma/migrations

3. Update your schema.prisma with the new provider:

prisma
datasource db {
  provider = "mysql"  // Your new provider
  url      = env("DATABASE_URL")
}

4. Update your DATABASE_URL to point to the new database.

5. Create a fresh migration history:

bash
npx prisma migrate dev --name init

This creates new migrations for the new provider and a new migration_lock.toml file.

5Option 3: Manually update migration_lock.toml (advanced)

Only do this if you're absolutely certain the existing migrations are compatible with your new provider (rare):

1. Edit prisma/migrations/migration_lock.toml:

toml
# Please do not edit this file manually
# It should be added in your version-control system (i.e. Git)
provider = "postgresql"  # Change to your desired provider

2. Run:

bash
npx prisma migrate resolve --applied <migration-name>

Warning: This is risky and can lead to migration failures. Only use this if you have simple migrations with compatible SQL across providers.

6Verify the fix

After applying your chosen solution, verify everything works:

bash
# Check migration status
npx prisma migrate status

# Generate Prisma Client
npx prisma generate

# Test database connection
npx prisma db pull

All commands should complete without the P3019 error.

Advanced notes

Multiple Environments with Different Providers

Some teams use SQLite for local development and PostgreSQL/MySQL for production. This pattern doesn't work well with Prisma Migrate because migrations are provider-specific. Instead:

- Use the same database provider in all environments (recommended)
- Use Docker to run your production database locally for development
- Use db push instead of migrate for local development (with caution)

Provider-Specific Migration Differences

Different providers have different SQL syntax and capabilities:
- PostgreSQL supports advanced features like JSONB, full-text search, and array types
- MySQL has different datetime handling and uses AUTO_INCREMENT instead of SERIAL
- SQLite has limited ALTER TABLE support and different type affinity rules

These differences mean migrations aren't portable between providers.

Migration History in Version Control

Always commit both your migrations folder and migration_lock.toml to version control. This ensures all team members and environments use the same provider and migration history.

Prisma db push vs Prisma migrate

If you don't need a migration history (e.g., rapid prototyping or local development), consider using prisma db push instead. It syncs your schema directly to the database without creating migrations or the migration_lock.toml file.

Frequently asked questions

What does "P3019" mean?
) your migrations were generated for. This file acts as a safeguard to prevent migrations created for one database system from being accidentally applied to a different one. toml file.
How do I fix "P3019"?
This error occurs when the database provider in your Prisma schema differs from the provider recorded in migration_lock.toml. It prevents applying migrations created for a different database system.
What causes "P3019"?
Changed the provider in schema.prisma datasource block (e.g., from postgresql to mysql) without resetting migration history Using migrations created in a different environment with a different database provider Cloned a repository and configured a different database provider than the original project
Is the "P3019" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading