Baselining an Existing Database in Prisma Without Running migrate reset

Point Prisma Migrate at a database that already has tables and data, and there is a good chance the first npx prisma migrate dev stops with a drift warning and offers to reset everything. That prompt is Prisma telling you that the database contains structure its migration history knows nothing about. Accepting it deletes your data. This guide explains why the conflict happens, why resetting is almost never the right answer for a database that matters, and how to baseline the existing schema so Prisma treats it as the starting point and only applies changes from there.

Why Prisma sees a conflict

Prisma Migrate keeps two records of your schema's evolution: the migration files in prisma/migrations and a table called _prisma_migrations inside the database that lists which of those files have been applied. When you run migrate dev, Prisma replays the migration history against a temporary shadow database and compares the result with the real one.

If the real database already has tables that no migration created, for example because it was built by hand, by another tool or by an earlier version of the app, the two do not match. Prisma calls that drift. Because migrate dev is a development command, its default remedy is to wipe the database and rebuild it from the migration history, so it proposes a reset. That is reasonable for a throwaway local database and destructive for anything else.

If you want more background on how the shadow database takes part in this comparison, see Prisma's shadow database and naming mismatches.

Why migrate reset is the wrong fix

npx prisma migrate reset drops the database, or every table in its schema, recreates it from your migrations and runs seed scripts. All existing rows are lost. On a database with real users, orders or content, that is not conflict resolution but data loss.

The better approach is to leave the database alone and instead bring Prisma's view of the world up to date with it. You do that by recording the current structure as a first migration and telling Prisma that this migration is already in place.

Baselining step by step

Step 1: Introspect the existing database

Run npx prisma db pull. Prisma connects to the database, reads its tables, columns, indexes and relations, and writes the corresponding models into schema.prisma. After this step the schema file describes the database exactly as it is.

Step 2: Generate a baseline migration without applying it

Create a folder for the baseline, for example prisma/migrations/0_init. The 0_ prefix makes it sort before any later, timestamped migrations. Then generate the SQL that would build the current schema from nothing and save it there, using npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql. In recent Prisma versions the target flag may be named --to-schema instead, so check npx prisma migrate diff --help for your version.

This step matters because it produces the migration file without touching the database. A common mistake is to run npx prisma migrate dev --name baseline at this point. Against a database that already has tables and no migration history, that command detects the same drift as before and asks to reset again, which is exactly what you are trying to avoid. The baseline SQL should never be executed against the existing database, because its tables already exist.

Step 3: Mark the baseline as applied

Run npx prisma migrate resolve --applied 0_init. The argument is the name of the migration folder. If a folder was created with a timestamp, such as 20250101120000_baseline, you must pass that full name, not just baseline.

This command does not run any SQL against your tables. It inserts a row into _prisma_migrations saying that the baseline has been applied. In effect you are editing Prisma's bookkeeping so that it accepts the current structure as intentional and valid.

How this resolves the conflict

It resembles a Git merge conflict: when your branch lacks commits already on main, you update the branch rather than delete main. Here the database is ahead, and you bring Prisma's history up to date with it.

After the baseline is recorded, the next npx prisma migrate dev replays 0_init in the shadow database, gets the same structure as the real database and finds no drift. From then on, when you change schema.prisma, Prisma generates a new migration containing only the difference and applies just that.

Why this matters for large databases

Baselining pays off most when the database holds a lot of data. With the baseline recorded in _prisma_migrations and the schema matching the live database, Prisma leaves existing tables and rows alone and applies only new changes, so your users table stays intact.

Keep a few practical points in mind:

• Run migrate resolve --applied once against every existing environment, such as staging and production, since each database has its own _prisma_migrations table.
• In production, apply later migrations with npx prisma migrate deploy, not migrate dev, which is meant for development only.
• Commit the baseline folder to version control so every developer and CI job shares the same starting point.

Key takeaways

• A drift warning on an existing database means Prisma's migration history is missing, not that the database is wrong.
• Resetting deletes data; treat it as a tool for disposable local databases only.
• Baseline by introspecting with db pull, generating SQL with migrate diff --from-empty, and recording it with migrate resolve --applied.
• Do not use migrate dev to create the baseline against a populated database, because it triggers the same reset prompt.
• After baselining, Prisma manages only incremental changes, and existing data stays untouched.