
## 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:

```bash
npx prisma db pull
```

This introspects the existing database and generates:

```txt
prisma/schema.prisma
```

At first, everything looks fine.

But later, when trying to create a new migration:

```bash
npx prisma migrate dev --name add_new_column
```

Prisma throws this:

```txt
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

```bash
mkdir -p prisma/migrations/init
```

---

## Step 2 — Generate the Baseline Migration SQL

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

```bash
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

```bash
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:

```bash
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:

```txt
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:

```txt
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:

```bash
npx prisma migrate resolve --rolled-back init
```

But Prisma returned:

```txt
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:

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

Then remove it manually:

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

Delete the migration folder:

```bash
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.



Prisma Baseline Migration


## The Problem

Sometimes your database already contains schema changes that are missing from your Prisma migration files.

In these situations:

- the actual database structure is ahead
- but Prisma migration history is behind

---

## The Goal

You want Prisma migrations to catch up with the current database state.

Instead of recreating everything from scratch, you can generate a migration representing the difference between:

- the current database
- and your current `schema.prisma`

---

## Step 1 — Create the Migration Folder

```bash
mkdir prisma/migrations/20260515000000_add_file_type
```

---

## Step 2 — Generate the Migration SQL

```bash
npx prisma migrate diff \
  --from-config-datasource \
  --to-schema prisma/schema.prisma \
  --script > prisma/migrations/20260515000000_add_file_type/migration.sql
```

This generates SQL representing the difference between:

- the configured datasource database
- and your Prisma schema

---

## Important Reminder

Always inspect the generated SQL before applying or marking migrations.

Prisma will generate SQL based purely on detected differences.

So if your schema contains accidental changes, those will also appear in the generated migration.

---

## Final Thoughts

`prisma migrate diff` is one of Prisma's most useful recovery tools.

Especially when working with existing databases or repairing migration drift.

Understanding the difference between:

- database state
- Prisma schema
- migration history

makes Prisma migrations much easier to reason about.


postgresql

Prisma Baseline Migration

Prisma sync migration gap