P3018: A migration failed to apply. New migrations cannot be applied before the error is recovered from.

TL;DR: A migration died halfway and Prisma froze the history until you resolve it. Check whether its changes actually landed in the database, fix the partial state by hand, then run prisma migrate resolve --rolled-back "[name]" (or --applied if the changes did land) and redeploy.

Error: P3018: A migration failed to apply. New migrations cannot be applied before the error is recovered from.

Steps

1. Find the failed migration:

   npx prisma migrate status

Expected: it names the failed migration and shows everything after it as blocked.

1. Inspect what actually landed. Compare the migration SQL against the real database (for example, check whether the table or column exists).

Expected: you can answer yes or no to 'did the failed migration's changes get applied?'

1. Resolve it honestly:

• Changes did NOT land: repair any partial state manually, then

     npx prisma migrate resolve --rolled-back "20240102_add_orders"

• Changes DID land (the failure was after the DDL, e.g. in a data step):

     npx prisma migrate resolve --applied "20240102_add_orders"

Expected: Migration 20240102_add_orders marked as rolled back. (or applied).

1. Fix the migration file if it was buggy, then redeploy:

   npx prisma migrate deploy

Expected: the fixed migration applies and later ones follow.

When to use

• The exact code is P3018 and migrate status shows a failed migration blocking the queue
• A deploy died mid-migration (OOM, statement timeout, bad SQL)

When not to use

• P3006: the failure was on the shadow database, the real database is untouched
• You want to undo a migration that applied cleanly: write a new migration instead, Prisma has no down migrations

Compatibility

Prisma Migrate 3.x through 6.x. PostgreSQL, MySQL, SQL Server.

Variant phrasing: P3018 with database error: relation already exists

The DDL half-applied before the crash. Drop the partially created objects by hand, then resolve as rolled back.

Why it happens

Prisma records each migration as failed in _prisma_migrations and refuses to run anything newer until a human declares the outcome. --rolled-back means 'I cleaned up, pretend it never ran'; --applied means 'the changes are really there, record it as done'. Picking the wrong one corrupts the history, so the manual inspection in step 2 is the whole job.

Edge cases

• Never edit a failed migration file and re-run deploy without resolving: Prisma checksums the file and the history row stays failed.
• On production, practice the manual repair on a restored copy first.
• If the failed migration is the very first one and the database is otherwise empty, migrate reset on a scratch database is simpler than surgery.