Drift detected: Your database schema is not in sync with your migration history

TL;DR: Something changed the database without going through migrations. Decide which side is right: if the database changes were intentional, turn them into a migration; if they were accidental, reset the database back to the history. Then migrate dev works again.

Drift detected: Your database schema is not in sync with your migration history.

Steps

1. See exactly what drifted:

   npx prisma migrate diff --from-migrations ./prisma/migrations --to-schema-datamodel prisma/schema.prisma --shadow-database-url "$SHADOW_DATABASE_URL"

Expected: a diff showing the statements that differ between history and schema.

1. If the database changes were INTENTIONAL (a hotfix applied by hand, a DBA change):

   npx prisma migrate dev --name capture_manual_changes

Expected: Prisma generates a migration from the drift and applies it; history and database agree again.

1. If the changes were ACCIDENTAL (someone ran db push, a script wrote DDL):

   npx prisma migrate reset

Expected: the dev database is rebuilt from the migration history; drift gone. Only do this where data loss is acceptable.

1. Re-run npx prisma migrate dev.

Expected: no drift error; normal migration flow resumes.

When to use

• The exact message is Drift detected on migrate dev
• Someone edited the database directly, ran db push, or restored a dump over the dev database

When not to use

• Production: never migrate reset there; capture the drift as a migration or reconcile by hand
• The message is P3018 instead: a migration failed, which is a different recovery

Compatibility

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

Variant phrasing: drift after a teammate ran prisma db push

db push changes the database without writing history. The push was probably intentional, so capture it with migrate dev --name as in step 2.

Why it happens

Prisma Migrate treats the migration history as the single source of truth. Any DDL that bypasses it (manual SQL, db push, restores) makes the database disagree with history, and migrate dev stops rather than build on a foundation it cannot verify.

Edge cases

• db push accepts data loss by design; teams that mix push and migrate hit drift constantly. Pick one workflow per environment.
• If drift reappears on every run, something in your pipeline writes DDL outside migrations; find it before reconciling again.
• Shadow database URL problems can masquerade as drift; make sure the diff command actually ran before trusting its output.