Prisma "Drift detected" - Schema Out of Sync with Migrations
Prisma compared the database to its recorded migration history and found differences it cannot explain. Something changed the schema outside of migrations - Prisma will not guess how to reconcile it.
What this error means
prisma migrate dev (or migrate diff/status) reports drift and, in development, may want to reset the database. It is deterministic and signals a real divergence between the schema and the migrations folder.
Drift detected: Your database schema is not in sync with your migration history.
The following is a summary of the differences ...
[+] Added column `note` on table `orders`
[-] Removed index `orders_status_idx`Common causes
Manual change applied outside migrations
Someone ran ad-hoc SQL or used db push against the database, so its schema no longer matches the migration history.
Migrations edited after being applied
Changing the SQL of a migration that already ran makes the recorded checksum and the database disagree, which reads as drift.
A shared database mutated by another branch
CI pointed at a long-lived shared database that another branch or process altered, diverging from this branch’s migration set.
How to fix it
Capture the drift as a new migration
If the database change is intended, generate a migration that records it so history and schema agree again.
npx prisma migrate diff \
--from-migrations ./prisma/migrations \
--to-schema-datasource ./prisma/schema.prisma \
--script > prisma/migrations/000_reconcile/migration.sqlUse a clean database per CI run
Run migrations against a fresh, ephemeral database so no out-of-band change can cause drift.
services:
db:
image: postgres:16 # fresh DB each run, migrate deploy applies full historyStop hand-editing applied migrations
- Never change a migration’s SQL after it has been applied anywhere.
- Add new migrations for further changes instead of editing old ones.
- Keep
db pushfor prototyping only, never against a migration-managed database.
How to prevent it
- Apply all schema changes through migrations, never ad-hoc SQL or
db push. - Use an ephemeral database per CI run so state is reproducible.
- Treat applied migrations as immutable.