Learn how to safely recover from Prisma P3018 migration failures on production PostgreSQL. Fix failed migrate deploy issues, resolve schema drift, validate Prisma schema, and restore deployments safely.
If you run production apps with Next.js, Prisma, and PostgreSQL, sooner or later you’ll likely hit this error:
Error: P3018
A migration failed to apply.
New migrations cannot be applied before the error is recovered from.Few deployment errors trigger panic faster.
Your production app is waiting for the database update.
Your deployment pipeline is blocked.
And every failed retry risks making things worse.
The good news: Prisma P3018 is recoverable — if you approach it correctly.
This guide walks through the exact production-safe workflow for diagnosing, resolving, and safely recovering from Prisma P3018 migration failures.
In real production environments, P3018 usually appears because of one of these causes:
Production database schema no longer matches Prisma migration history.
This often happens when:
---
A generated migration contains SQL that fails on production.
Examples:
---
Migration started successfully, then failed midway.
This leaves production in an inconsistent state.
---
Existing data violates new schema constraints.
Examples:
---
Local development database differs from production.
This is extremely common in self-hosted deployments.
---
migrate deployWhen P3018 appears, do not repeatedly run:
npx prisma migrate deployRepeated attempts can:
Pause deployment first.
Inspect state.
Recover intentionally.
---
Before touching anything, create a full backup.
pg_dump -U postgres -Fc your_database > backup_$(date +%F).dumpExample:
pg_dump -U postgres -Fc zageneral > backup_2026-05-31.dumpThis gives you a recovery point if things go wrong.
Never skip this.
---
Inspect Prisma migration state:
npx prisma migrate statusYou may see output like:
Following migration have failed:
20260531120000_add_articles_tableThis identifies the failed migration.
---
Inspect the migration tracking table:
SELECT migration_name, finished_at, rolled_back_at, logs
FROM "_prisma_migrations";Look for:
finished_at = NULLThis tells you exactly where migration failed.
---
Open the failed migration:
prisma/migrations/<migration_name>/migration.sqlLook for problematic operations such as:
ALTER TABLE "articles"
ADD CONSTRAINT "articles_slug_key" UNIQUE ("slug");If duplicate slugs already exist, this will fail.
This is one of the most common real-world causes.
---
There are two safe recovery approaches.
---
Use this when the migration failed before meaningful schema changes were applied.
npx prisma migrate resolve --rolled-back "<migration_name>"Example:
npx prisma migrate resolve --rolled-back "20260531120000_add_articles_table"Then fix the migration and redeploy:
npx prisma migrate deploy---
Use this when:
npx prisma migrate resolve --applied "<migration_name>"Example:
npx prisma migrate resolve --applied "20260531120000_add_articles_table"This updates Prisma history without rerunning SQL.
---
Never mark a migration as applied unless the schema truly matches.
Validate first.
---
Run:
npx prisma validateThen regenerate Prisma client:
npx prisma generateFinally compare schema:
npx prisma db pullIf pulled schema differs from your Prisma schema, drift still exists.
Fix it before proceeding.
---
Once migration state is healthy:
npm install
npm run buildIf using PM2:
pm2 restart your-app---
A successful migration command is not enough.
Validate runtime health.
---
pm2 statusLook for:
---
pm2 logs your-app --lines 100Watch for:
---
Verify actual app functionality.
Examples:
If these work, recovery succeeded.
---
If recovery fails:
Restore database backup:
pg_restore -U postgres -d your_database backup.dumpThen redeploy previous known-good app version.
This is why backups matter.
---
Production migration failures are usually preventable.
Use this checklist:
Never deploy untested schema changes directly.
---
Run:
npx prisma migrate diff---
Direct PostgreSQL changes create drift.
---
Always inspect:
migration.sqlbefore production deployment.
---
Nightly backups reduce recovery risk dramatically.
---
When Prisma P3018 happens in production, this is my exact sequence:
pg_dump -U postgres -Fc appdb > backup.dump
npx prisma migrate status
SELECT * FROM "_prisma_migrations";
npx prisma migrate resolve --rolled-back "<migration>"
npx prisma migrate deploy
npm run build
pm2 restart app
pm2 logs appThis minimizes downtime while preserving safety.
---
Prisma P3018 looks intimidating because it blocks deployments at the database layer.
But in reality, it is Prisma protecting your production data.
The fix is simple:
Production recovery is not about speed.
It is about precision.