Bug description

After upgrading to Prisma 7.4.0, 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 @@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

1. Run prisma migrate dev --create-only --name add_partial_index
2. Edit the generated migration.sql to add a partial index
3. Apply with prisma migrate dev
4. Now, without making any schema changes, run prisma migrate dev --create-only --name empty
5. 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?

Yes, last worked in Prisma 7.0.1, broke in 7.4.0

Workaround

No workaround found. I try to downgrade to version 7.2.0 and still every migration include drop index statements

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.0