Error: Prisma Migrate detected that the database schema has drifted from the migration history.

The following is a summary of the differences between the expected database schema
given your migration files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

This error means your actual database schema doesn’t match what Prisma’s migration history says it should be. Something changed the database outside of Prisma Migrate.

What causes this

Prisma Migrate tracks every schema change as a migration file in prisma/migrations/. When you run prisma migrate dev, it compares the current database schema against the expected state from all applied migrations. If they don’t match, it reports a drift.

Common triggers:

• Someone modified the database directly (manual SQL, another ORM, a database GUI)
• You ran prisma db push which changes the schema without creating a migration
• A migration was manually deleted from the prisma/migrations/ folder
• The _prisma_migrations table was modified or cleared
• You’re pointing at a database that was set up by a different branch or project

Fix 1: Reset in development

If you’re in development and don’t care about the data, reset everything:

npx prisma migrate reset

This drops the database, recreates it, runs all migrations from scratch, and re-seeds (if you have a seed script). All data is lost.

⚠️ Only use this in development. Never on a production database.

Fix 2: Create a new migration to reconcile

If the drift is from intentional changes (e.g., you used db push during prototyping and now want to formalize it), create a migration that captures the current state:

# Generate a migration based on the diff between schema.prisma and the database
npx prisma migrate dev --name reconcile_drift

Prisma will detect the drift and ask if you want to reset or create a migration. If the changes are additive (new columns, new tables), it can often generate the right migration automatically.

Fix 3: Baseline an existing database

If you’re adopting Prisma Migrate on a database that already has a schema (from raw SQL or another tool), you need to baseline it:

# 1. Create an initial migration without applying it
npx prisma migrate diff \
  --from-empty \
  --to-schema-datamodel prisma/schema.prisma \
  --script > prisma/migrations/0_init/migration.sql

# 2. Create the migrations directory structure
mkdir -p prisma/migrations/0_init

# 3. Mark it as already applied
npx prisma migrate resolve --applied 0_init

This tells Prisma “the database already matches this migration — don’t try to run it.”

Fix 4: Mark a specific migration as applied

If a migration was applied manually (via raw SQL) and Prisma doesn’t know about it:

npx prisma migrate resolve --applied "20240101000000_add_users_table"

This inserts a record into the _prisma_migrations table without actually running the SQL. Use this when you know the database already has the changes from that migration.

Fix 5: Mark a failed migration as rolled back

If a migration partially failed and you’ve manually cleaned up:

npx prisma migrate resolve --rolled-back "20240101000000_add_users_table"

This marks the migration as not applied, so you can fix the SQL and re-run it.

Related resources

• Prisma cheat sheet

How to prevent it

• Never modify the database schema directly. All changes should go through prisma migrate dev (development) or prisma migrate deploy (production).
• Use prisma db push only during early prototyping. Switch to prisma migrate dev once your schema stabilizes.
• Don’t delete migration files from prisma/migrations/. If you need to squash migrations, create a baseline migration instead.
• Run prisma migrate status in CI to catch drift before deploying.

Related: Prisma: Environment Variable Not Found — How to Fix It