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.
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.
Check your current schema.prisma configuration:
// prisma/schema.prisma
datasource db {
provider = "postgresql" // or "mysql", "sqlite", etc.
url = env("DATABASE_URL")
}Then check the migration_lock.toml file:
cat prisma/migrations/migration_lock.tomlYou'll see output like:
# 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.
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.
If you accidentally changed the provider and want to go back:
1. Update your schema.prisma to match migration_lock.toml:
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:
npx prisma migrate deployThis approach preserves your migration history and data.
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:
rm -rf prisma/migrations3. Update your schema.prisma with the new provider:
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:
npx prisma migrate dev --name initThis creates new migrations for the new provider and a new migration_lock.toml file.
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:
# 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 provider2. Run:
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.
After applying your chosen solution, verify everything works:
# Check migration status
npx prisma migrate status
# Generate Prisma Client
npx prisma generate
# Test database connection
npx prisma db pullAll commands should complete without the P3019 error.
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.
P1013: The provided database string is invalid
The provided database string is invalid
P1000: Authentication failed against database server
Authentication failed against database server
P1010: User was denied access on the database
How to fix "P1010: User was denied access on the database" in Prisma
P5008: Usage exceeded, upgrade your plan (Accelerate)
How to fix "Usage exceeded, upgrade your plan" in Prisma Accelerate
P3021: Foreign keys cannot be created on this database
How to fix 'P3021: Foreign keys cannot be created on this database' in Prisma