Running `prisma migrate dev` against Supabase with `multiSchema` throws error: `db error: ERROR: cannot drop table

TL;DR

[janpio (maintainer)]: The drift is detected because you introspected with db pull (which creates no migration history) and then ran migrate dev, which compares against migration history.

Steps

1. [janpio (maintainer)]: The drift is detected because you introspected with db pull (which creates no migration history) and then ran migrate dev, which compares against migration history. Fix: baseline the database first (see Prisma's "baseline your database" docs) so migrate dev sees no drift and never prompts a reset. Going forward, Prisma 6.13.0 made multiSchema GA with "external tables": list Supabase-managed system tables in prisma.config.ts so Prisma leaves them alone.

When to use

You are seeing this: Prisma - ### Bug description prisma migrate dev command fails when using multiSchema with Supabase. Use this skill when you run into "Running prisma migrate dev against Supabase with multiSchema throws error: `db error: ERROR: cannot drop table".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: Prisma 6.13.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/prisma/orm/issues/17734

In gh:prisma/orm#17734 (https://github.com/prisma/orm/issues/17734), the issue reported: ### Bug description prisma migrate dev command fails when using multiSchema with Supabase. ### How to reproduce 1. Create a new Supabase project and copy the database connection string. Make sure to set up and use the shadow database by following this: https://supabase.com/docs/guides/integrations/prisma 2. Create a new Nuxt3 app and set up environmental variables 3. Set your schema.prisma as shown below 4. Run prisma db pull to pull to introspect. This will pull all tables in public and auth schema 5. Run prisma generate 6. Next, run prism migrate dev --name init 7. The verified answer: [janpio (maintainer)]: The drift is detected because you introspected with db pull (which creates no migration history) and then ran migrate dev, which compares against migration history. Fix: baseline the database first (see Prisma's "baseline your database" docs) so migrate dev sees no drift and never prompts a reset. Going forward, Prisma 6.13.0 made multiSchema GA with "external tables": list Supabase-managed system tables in prisma.config.ts so Prisma leaves them alone.