Prisma Baseline Migration

3 min read

How to create a proper baseline migration after using prisma db pull — and how I fixed a migration drift mistake.

prismapostgresqldatabasemigrations

The Situation

When working with Prisma on an existing database, there are actually 3 separate things involved:

  • The actual database
  • schema.prisma
  • Migration files

Your database already contains:

  • tables
  • columns
  • relationships
  • existing data

So naturally, the first thing many developers do is:

npx prisma db pull

This introspects the existing database and generates:

prisma/schema.prisma

At first, everything looks fine.

But later, when trying to create a new migration:

npx prisma migrate dev --name add_new_column

Prisma throws this:

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

Why This Happens

prisma db pull only generates schema.prisma.

It does not generate migration history.

So Prisma now sees:

  • a real database schema
  • a Prisma schema
  • but no migration history explaining how the database reached this state

As far as Prisma is concerned, the current database structure came from nowhere.

So Prisma does not know how to build the next migration safely.

The Correct Way: Create a Baseline Migration

You need to create an initial migration that represents the current database structure.

This is called a baseline migration.

Step 1 — Create the Migration Folder

mkdir -p prisma/migrations/init

Step 2 — Generate the Baseline Migration SQL

Generate SQL from an empty database to your current Prisma schema:

npx prisma migrate diff \
  --from-empty \
  --to-schema prisma/schema.prisma \
  --script > prisma/migrations/init/migration.sql

This creates a migration file containing the full schema.

Step 3 — DO NOT Run the Migration

This part is important.

Your database already contains the tables.

Running the migration again would attempt to recreate everything.

Instead, you only want Prisma to acknowledge:

"Yes, this migration already happened."

Step 4 — Mark the Migration as Applied

npx prisma migrate resolve --applied init

This inserts the migration into Prisma's migration history table.

Now Prisma finally understands the current database state.

Step 5 — Create Future Migrations Normally

Now future migrations work properly:

npx prisma migrate dev --name add_accountType_to_account

The Mistake I Made

I accidentally added a new column to schema.prisma before generating the baseline migration.

So my baseline migration already included the new column.

Then later I removed the column from schema.prisma and tried creating a migration again.

Prisma complained:

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

[*] Changed the `Account` table
  [-] Removed column `accountType`

Why This Error Happens

The baseline migration had already been marked as applied.

So Prisma now believes:

accountType already exists in production history

Simply editing schema.prisma afterward does not change migration history.

Prisma migrations are append-only.

Once a migration is considered applied, Prisma expects the database and migration history to stay aligned.

A Common Misunderstanding About resolve --rolled-back

I initially tried this:

npx prisma migrate resolve --rolled-back init

But Prisma returned:

Migration `init` cannot be rolled back because it is not in a failed state.

This is because:

  • resolve --rolled-back ❌ does NOT mean "undo migration"
  • it only means:

    "mark a failed migration as rolled back"

It is purely metadata handling.

It does not revert schema changes.

How I Fixed It

First, check the migration record:

SELECT *
FROM "_prisma_migrations"
WHERE migration_name = 'init';

Then remove it manually:

DELETE FROM "_prisma_migrations"
WHERE migration_name = 'init';

Delete the migration folder:

rm -rf prisma/migrations/init

Then regenerate everything properly.

Most importantly:

  • remove accidental schema changes first
  • make sure schema.prisma exactly matches the current database
  • then regenerate the baseline migration

Important Lesson

A Prisma baseline migration should represent:

the exact current database state

Nothing more.

Do not mix future schema changes into the baseline migration.

Otherwise Prisma's migration history and actual database state will diverge immediately.

Final Thoughts

prisma db pull is only schema introspection.

It is not migration history reconstruction.

When adopting Prisma on an existing database:

  1. introspect the schema
  2. create a baseline migration
  3. mark it as applied
  4. only then start creating new migrations

Once the baseline is correct, Prisma migrations become predictable again.