Prisma throws P3011 when you try to mark a migration as rolled back even though it never ran — the CLI only allows `migrate resolve --rolled-back` on migrations that failed during execution.
Fixes P3011: Migration cannot be rolled back because it was never applied
SELECT migration_name, applied_steps_count, finished_at, status, failed_at
FROM "_prisma_migrations"
WHERE migration_name = '20220714121901_add_profile';SELECT migration_name, applied_steps_count, finished_at, status, failed_atFROM "_prisma_migrations"WHERE migration_name = '20220714121901_add_profile';P3011: Migration cannot be rolled back because it was never applied
P3011 means that Prisma already knows this migration was never applied, so there is nothing to revert. The `migrate resolve --rolled-back <name>` command is only valid for migrations that ran but stopped with an error; it toggles the `_prisma_migrations` record from `failed` to `rolledBack`. If the migration never reached the database (either it was newly created or you pointed at the wrong database), Prisma refuses the rollback because it would leave the migration history inconsistent. Use `prisma migrate status` or query `_prisma_migrations` to see whether the migration has `applied_steps_count > 0` or a `failed_at` timestamp before you attempt to resolve it.
Ask Prisma about the status of the offending migration with npx prisma migrate status --schema prisma/schema.prisma. If you prefer SQL, query the migrations table directly:
SELECT migration_name, applied_steps_count, finished_at, status, failed_at
FROM "_prisma_migrations"
WHERE migration_name = '20220714121901_add_profile';If applied_steps_count is 0 and failed_at is null, the migration never touched the database and cannot be marked as rolled back.
If your migration was created locally but never applied, there is no “rollback” to run. Delete the folder inside prisma/migrations/<timestamp>_name, then rerun npx prisma migrate dev (or generate a fresh migration with npx prisma migrate diff/npx prisma migrate dev --name <new>). This keeps the history in sync without touching _prisma_migrations.
When a migration fails to apply, _prisma_migrations records failed_at. That is the only time prisma migrate resolve --rolled-back <name> should be used. Double-check the row before running the command, then execute:
npx prisma migrate resolve --rolled-back 20220714121901_add_profileIf the migration is still marked as failed, this command clears the failure and allows the next deployments to start from scratch.
Prisma does not generate automatic down migrations. To undo a schema change that already succeeded, author a new migration that puts the schema back in the desired state (for example, drop the column or revert the default). Alternatively, use npx prisma migrate diff --from-schema-datasource --to-schema-datamodel --script > rollback.sql to craft manual SQL and update _prisma_migrations rows so the CLI stays aware of the history.
The migrate resolve command is documented to operate on failed migrations only, so it will always throw P3011 when the history table records no failure. Production troubleshooting guides still recommend resolving failed migrations by marking them as rolled back so you can reapply them, but the migration must actually have failed first. If you keep hitting P3011 after confirming the row exists, verify that DATABASE_URL points to the environment you expect; running the command against the wrong database often looks like an un-applied migration.