Prisma detects that your schema changes would cause data loss. This occurs when adding required fields without defaults, dropping columns, or changing field constraints. Resolve it by modifying your schema, using the --accept-data-loss flag carefully, or customizing migrations.
The P3001 error occurs when Prisma Migrate detects that applying your schema changes would destroy or lose data. This is a safety mechanism that prevents accidental data destruction. Prisma analyzes the difference between your current schema and your Prisma model definitions, and if it determines that existing database data would be deleted or irreversibly modified, it blocks the migration and asks you to confirm.
Run npx prisma migrate dev to see the detailed warning message. Prisma will tell you exactly which change is destructive. For example: "The migration will add a required column status without a default value to the User table which currently has 5 rows."
If you're adding a required field, add a default value in your schema:
model User {
id Int @id @default(autoincrement())
name String @default("Unknown") // Add @default()
email String @unique
}Then run npx prisma migrate dev --name add_name_field
If you can't provide a sensible default, make the field optional first:
model User {
id Int @id @default(autoincrement())
name String? // Optional with ?
email String @unique
}Run the migration, backfill the data with your application, then make it required in a second migration.
For sophisticated changes (renaming fields, transforming data), create a migration without applying it:
npx prisma migrate dev --name transform_user_status --create-onlyThis creates the migration file in prisma/migrations/ but doesn't apply it. Edit the SQL file to add your custom data transformation logic, then run npx prisma migrate dev again to apply it.
If you're in development and the data doesn't matter, you can reset:
npx prisma migrate resetOR accept data loss for a single migration:
npx prisma migrate dev --name my_migration
# When prompted, choose to reset the databaseNEVER use these approaches in production.
For production databases:
1. Deploy migration 1: Add new nullable column
newStatus String?2. Deploy your application code to backfill the column with values
3. Deploy migration 2: Make the column required
newStatus String @default("pending")4. Remove the old column in a follow-up migration
This prevents data loss and allows rollback at each step.
Always review generated migrations before applying them:
cat prisma/migrations/*/migration.sqlEnsure it matches your expectations. If Prisma generated incorrect SQL (rare), edit the migration file before applying it. For detailed info, see the Prisma Migrate customization guide.
For renaming columns without data loss: Create a migration with --create-only, then manually edit the SQL to use ALTER TABLE ... RENAME COLUMN instead of dropping and creating. For changing field types: Write custom SQL using ALTER TABLE ... USING in PostgreSQL or appropriate syntax for your database. Database schema drift can also trigger P3001 if your database doesn't match migration historyβuse npx prisma migrate resolve --rolled-back <migration_id> to mark failed migrations. For team workflows, always commit migration files and run migrations before development to avoid conflicts.
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