How to fix P3002: The attempted migration was rolled back: {database_error} in Prisma

PrismaINTERMEDIATEHIGHUpdated Dec 22, 2025· 100 views

This Prisma Migrate error occurs when a database migration fails during execution and is automatically rolled back. The migration remains in a failed state and must be resolved before new migrations can be applied.

Quick fix

Fixes P3002

npx prisma migrate status
  1. Check the migration failure details
  2. Mark the migration as rolled back
  3. Fix the migration file
  4. Reapply the migration
prisma — error
npx prisma migrate status
P3002: The attempted migration was rolled back: {database_error}
shell
npx prisma migrate status

What this error means

The P3002 error is a Prisma Migrate error that indicates a migration failed to apply completely and was automatically rolled back by the database. When a migration is executed, Prisma attempts to apply all schema changes within a transaction. If any step fails—whether due to syntax errors, constraint violations, or incompatible schema changes—the database automatically reverses all changes made during that migration to maintain data integrity. This error prevents further migrations from running until the failed migration is resolved. The error message includes the underlying database error that caused the rollback, which is essential for diagnosing the root cause. The migration is recorded in the _prisma_migrations table with a failed status, and the logs column contains details about what went wrong. Understanding this error is critical for maintaining a healthy migration workflow, especially in production environments where manual intervention may be required to fix and reapply migrations.

Typical symptoms

  • Migration fails with "P3002: The attempted migration was rolled back" message
  • Subsequent prisma migrate deploy or prisma migrate dev commands fail
  • Migration appears in _prisma_migrations table with failed status
  • Error message includes underlying database error details
  • CI/CD pipelines fail during database migration step
  • Local development database cannot sync with schema changes

Common causes

  1. SQL syntax errors in the migration file
  2. Foreign key constraint violations when dropping or modifying tables
  3. Unique constraint violations during data migrations
  4. Attempting to add NOT NULL columns to tables with existing data
  5. Database-specific limitations (e.g., PostgreSQL cannot alter enum values in a transaction)
  6. Insufficient database permissions for the migration operations
  7. Schema changes that conflict with existing data
  8. Concurrent migration attempts in multi-instance deployments
  9. Database connection interrupted during migration execution

How to fix "P3002: The attempted migration was rolled back: {database_error}"

1Check the migration failure details

First, examine the error message to identify the underlying database error that caused the rollback:

bash
npx prisma migrate status

You can also query the _prisma_migrations table directly to see the error logs:

sql
SELECT migration_name, logs, finished_at
FROM _prisma_migrations
WHERE finished_at IS NULL OR logs IS NOT NULL;

The logs column contains the detailed database error that will guide your fix. Common errors include constraint violations, type mismatches, or permission issues.

2Mark the migration as rolled back

Once you understand why the migration failed, mark it as rolled back so it can be reapplied:

bash
npx prisma migrate resolve --rolled-back "migration_name"

Replace "migration_name" with the actual migration folder name (e.g., "20240101120000_add_user_table"). This updates the _prisma_migrations table to register the migration as rolled back, allowing it to be applied again.

Note: This command only works with failed migrations. It cannot be used on successfully applied migrations.

3Fix the migration file

Based on the error logs, edit the migration SQL file to fix the issue. Common fixes include:

For NOT NULL constraints:

sql
-- Add column with a default value first
ALTER TABLE "User" ADD COLUMN "email" TEXT DEFAULT 'placeholder@example.com';

-- Then update existing rows
UPDATE "User" SET "email" = 'user_' || id || '@example.com' WHERE "email" IS NULL;

-- Finally, set NOT NULL constraint
ALTER TABLE "User" ALTER COLUMN "email" SET NOT NULL;
ALTER TABLE "User" ALTER COLUMN "email" DROP DEFAULT;

For foreign key constraints:

sql
-- Drop dependent foreign keys first
ALTER TABLE "Post" DROP CONSTRAINT "Post_authorId_fkey";

-- Make your changes
ALTER TABLE "User" RENAME COLUMN "id" TO "userId";

-- Recreate foreign keys
ALTER TABLE "Post" ADD CONSTRAINT "Post_authorId_fkey"
  FOREIGN KEY ("authorId") REFERENCES "User"("userId");

After editing, copy the fixed migration back to your source control.

4Reapply the migration

After fixing the migration file and marking it as rolled back, attempt to reapply it:

For development:

bash
npx prisma migrate dev

For production:

bash
npx prisma migrate deploy

If the migration still fails, repeat the process: check the logs, fix the issue, mark as rolled back, and try again.

5Alternative: Reset in development

If you're in a development environment and can afford to lose data, the simplest solution is to reset your database:

bash
npx prisma migrate reset

This drops the database, recreates it, applies all migrations from scratch, and runs your seed script. This is the fastest way to recover from failed migrations during local development.

Warning: Never use this in production as it deletes all data.

Advanced notes

Production migration strategies: In production environments, you may need to manually complete partially applied migrations. If a migration partially succeeded before rolling back, inspect the database state carefully. You might need to manually revert some changes before marking the migration as rolled back.

Shadow database and development: Prisma uses a shadow database during development to detect schema drift and validate migrations. If your shadow database lacks necessary permissions or resources, migrations may fail. Ensure the shadow database has the same capabilities as your main database.

Handling enum changes: PostgreSQL cannot alter enum types within a transaction. If you're adding or removing enum values, you may need to split the migration into multiple steps or use a workaround that creates a new enum type and migrates data outside the transaction.

Baseline migrations: If you're integrating Prisma Migrate into an existing database, use prisma migrate resolve --applied to mark initial migrations as already applied without running them. This prevents rollbacks due to already-existing schema elements.

Multi-instance deployments: In environments with multiple application instances, ensure only one instance runs migrations at a time. Use deployment orchestration tools to sequence migrations before scaling up instances, or implement migration locks to prevent concurrent execution.

Down migrations: While Prisma Migrate doesn't natively support down migrations, you can use prisma migrate diff to generate a rollback SQL script. Store these alongside your migrations for emergency rollback scenarios in production.

Frequently asked questions

What does "P3002" mean?
The P3002 error is a Prisma Migrate error that indicates a migration failed to apply completely and was automatically rolled back by the database. When a migration is executed, Prisma attempts to apply all schema changes within a transaction. If any step fails—whether due to syntax errors, constraint violations, or incompatible schema changes—the database automatically reverses all changes made during that migration to maintain data integrity.
How do I fix "P3002"?
This Prisma Migrate error occurs when a database migration fails during execution and is automatically rolled back. The migration remains in a failed state and must be resolved before new migrations can be applied.
What causes "P3002"?
SQL syntax errors in the migration file Foreign key constraint violations when dropping or modifying tables Unique constraint violations during data migrations
Is the "P3002" 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