Bug description

Bug description
After upgrading to Prisma 7.4.2, prisma migrate dev now generates DROP INDEX statements for partial indexes (indexes with WHERE clauses) that were manually added to migration SQL files months ago.
These partial indexes cannot be represented in the Prisma schema because Prisma does not support the WHERE clause in @https://github.com/unique / @@index (see #6974). The recommended approach has always been to add them as custom SQL inside migration files, which is exactly what we did.
Previously, the migration engine did not detect these partial indexes during the shadow database diff, so they were left untouched. After upgrading to Prisma 7.4.0, the engine now detects them and — since they have no corresponding declaration in schema.prisma — treats them as drift and generates DROP INDEX to remove them.
This happens on every prisma migrate dev invocation, regardless of whether there are actual schema changes. The generated migration always includes:
DROP INDEX "<index_name>";
This effectively means partial indexes created via the officially recommended workflow (customizing migrations) are no longer safe across Prisma upgrades.

Severity

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

Reproduction

Run prisma migrate dev --create-only --name add_partial_index
Edit the generated migration.sql to add a partial index
Apply with prisma migrate dev
Now, without making any schema changes, run prisma migrate dev --create-only --name empty
Inspect the generated migration.sql — it contains: DROP INDEX "<partial_index_name>";

Expected vs. Actual Behavior

Expected: Partial indexes added via custom SQL in migrations (the officially recommended workflow per Prisma docs) should be preserved across future migrations. The migration engine should not generate DROP INDEX for indexes it cannot represent in the schema.
Actual: The migration engine detects the partial indexes in the shadow database, recognizes they have no corresponding @@unique/@@index in schema.prisma, and generates DROP INDEX statements to remove them.

Frequency

Consistently reproducible

Does this occur in development or production?

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

Is this a regression?

Workaround

Prisma Schema & Queries

// Add relevant schema.prisma snippet

// Add relevant Prisma Client query

Prisma Config

// Add your `prisma.config.ts`

Logs & Debug Info

// Debug logs here

Environment & Setup

• OS:
• Database:
• Node.js version:

Prisma Version

7.4.2