`prisma migrate diff` won't detect indexes, yet index differences require a full db reset

[CodeSmith32]

Bug description

I had a migration to run. I ran it. It completed successfully, and even noted that the database was in sync:

> prisma migrate dev --config ./src/prisma/prisma.config.ts

The following migration(s) have been applied:

...

Your database is now in sync with your schema.

I ran it once more, which should naturally just say something like, nothing to apply. Instead:

> prisma migrate dev --config ./src/prisma/prisma.config.ts

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

The following is a summary of the differences between the expected database schema given your migrations 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.

[*] Changed the `Foo` table
  [+] Added index on columns (barId)

We need to reset the MySQL database "<redacted>" at "localhost:3306"

With this issue, I'm stopped from running any further migrations. I was able to run one more somehow, by dropping my local database and reverting to an old version, and then applying several schema upgrades. I cannot keep reverting indefinitely.

---

So, more interestingly, I checked to see what the diff is:

npx prisma migrate diff --from-config-datasource --config .\src\prisma\prisma.config.ts --to-schema .\src\prisma\schema.prisma --script > diff.sql

diff.sql:

-- This is an empty migration.

---

Reproducible in v7.1.0 and v7.5.0.

Severity

⚠️ Major: Breaks core functionality (e.g., migrations fail)

Reproduction

This codebase is proprietary. I will try to work on a reproduction at some point.

Expected vs. Actual Behavior

I should not be getting a warning about an index differing. The database should be in sync.

Frequency

Consistently reproducible

Does this occur in development or production?

Only in development (e.g., CLI tools, migrations, Prisma Studio)

Is this a regression?

Not sure

Workaround

Currently, dropping my database and restoring an old backup a few migrations behind, and then fast-forwarding to the current version plus the next migration seems to allow me to apply new migrations. This obviously will not work long term.

Prisma Schema & Queries

model Foo {
  id          String   @id @unique @db.VarChar(36)
  submittedAt DateTime @default(now())
  barId       String   @unique @db.VarChar(36)
  bar         Bar      @relation("Foo_fkBar", fields: [barId], references: [id], onUpdate: Restrict, onDelete: Restrict)
}

Prisma Config

import "@repo/config/dotenv";
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "./schema.prisma",
  migrations: {
    path: "./migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
    shadowDatabaseUrl: env("SHADOW_DATABASE_URL"),
  },
});

Logs & Debug Info

N/A

Environment & Setup

• OS: Windows 11 (25H2)
• Database: MySQL (MariaDB 10.11.5)
• Node.js version: 22.22.0 (x64)

Prisma Version

prisma               : 7.5.0
@prisma/client       : 7.5.0
Operating System     : win32
Architecture         : x64
Node.js              : v22.22.0
TypeScript           : 5.8.3
Query Compiler       : enabled
PSL                  : @prisma/prisma-schema-wasm 7.5.0-15.280c870be64f457428992c43c1f6d557fab6e29e
Schema Engine        : schema-engine-cli 280c870be64f457428992c43c1f6d557fab6e29e (at node_modules\@prisma\engines\schema-engine-windows.exe)
Default Engines Hash : 280c870be64f457428992c43c1f6d557fab6e29e
Studio               : 0.21.1

[CodeSmith32]

Long story short, there apparently is an index on a foreign key that I do not recall adding, but appears to be the problem. prisma migrate diff refuses to show this difference.

There are now actually two issues I'm seeing here. I've linked related issues I could find, but they deal with fulltext indexes, whereas my index is just a plain KEY index:

1. Indexes are not always detected by prisma migrate diff.
   This issue recommends that fulltext indexes should not be discoverable using prisma migrate diff. I would be accepting of that for plain key indexes too, granted we can migrate with no complaints. Granted, I'm aware that indexes can be created with the @@index syntax in the Prisma schema. So, I'm not sure leaving out indexes from diffs makes sense.

2. A difference in an index should not require an entire database reset.
   This issue says that, for fulltext indexes, Prisma shouldn't even notice a difference. I'd say this should also apply for plain KEY indexes too. Or, if it does notice, it should show a warning, but should in no case require an entire db reset.