Prisma `migrate dev` Keeps Asking to Reset: What Schema Drift Actually Means

Why this feels so annoying: the CLI asks to reset your database, you panic because local data matters, and the message sounds like Prisma is being reckless. Usually the tool is not being reckless. It is telling you your migration history and actual database state no longer agree.

What schema drift means in plain language

Schema drift means the database you have right now does not match the migration history Prisma expects.

That can happen because:

1. someone changed the database manually
2. you switched branches with different migration files
3. a migration was edited after being applied
4. local state survived longer than the assumptions in the repo

The database is not “wrong” in a moral sense. It is just out of sync with the migration story.

Why branch switching causes so much trouble

Imagine branch A has one migration and branch B has another. If you apply one branch’s schema locally and then switch without reconciling, Prisma is now looking at a database shaped by a different history than the one in your working tree.

That is why the problem often appears after a harmless-looking checkout, not after a dramatic SQL event.

The command people see

npx prisma migrate dev

If Prisma detects drift, it may ask to reset the local database.

That is a big action, so do not approve it blindly. But also do not pretend the warning is random.

A better local mental model

Treat your local development database as rebuildable infrastructure, not as a sacred pet. If you absolutely need preserved local seed data, script the seed. Do not rely on hoping drift never happens.

That one mindset change makes Prisma much less emotionally expensive.

A safer workflow

When changing branches:

1. check whether migration history changed
2. decide whether your local DB should be rebuilt
3. reseed intentionally if needed

Useful commands:

npx prisma migrate status

and if you really need a clean rebuild:

npx prisma migrate reset

That reset is disruptive, but it is much healthier than carrying a misleading local schema for days.

What not to do

Do not edit old migration files casually

That is a good way to make history harder to trust.

Do not make manual schema changes and forget them

If the database changed outside Prisma’s migration story, drift is predictable.

Do not store irreplaceable local data without seed logic

You are making resets emotionally expensive for no good reason.

The real lesson

Prisma is not merely generating SQL. It is trying to keep a history of intended database state. Once you understand that, reset prompts feel less like random punishment and more like consistency checks.

Final recommendation

If Prisma keeps asking for a reset, do not fight the symptom first. Ask why your local database and migration history stopped telling the same story. Most of the pain comes from treating local state as permanent while also expecting migration history to stay authoritative.

Once you stop demanding both at the same time, Prisma becomes much less mysterious. It is trying to preserve a coherent history, and that only works if the local database is allowed to be rebuilt when the history changes meaningfully.

Sources

• Prisma migrate docs
• Prisma migrate dev docs