P3006: Migration `20240101_init` failed to apply cleanly to the shadow database.

TL;DR: P3006 is about the shadow database, not your real one. Some statement in the migration cannot run against a completely empty database. Find it, rewrite it so it works from empty, and the migration proceeds.

Error: P3006: Migration `20240101_init` failed to apply cleanly to the shadow database.

Steps

1. Read the full error output. Prisma prints the failing statement and the database's complaint below the P3006 line.

Expected: you can name the exact statement, for example a GENERATED ALWAYS AS column or a CREATE EXTENSION call.

1. Fix the usual suspects in the migration SQL:

• Generated columns referencing functions unavailable in the shadow database: simplify the expression or create it in a later migration.
• CREATE EXTENSION: the shadow database role may lack permission; pre-create the extension on the shadow database or move it to a manual setup step.
• Statements assuming existing data or tables: guard them or split them into a second migration.

Expected: the migration file now contains only statements that run on an empty database.

1. Re-run:

   npx prisma migrate dev

Expected: Your database is now in sync with your schema instead of P3006.

When to use

• The exact code is P3006 during migrate dev or migrate deploy
• The migration works on your dev database but fails in CI or on a teammate's machine

When not to use

• The migration failed on the real database: that is P3018, and the recovery is different
• The error is about drift between schema and history: that is the drift error, not P3006

Compatibility

Prisma Migrate 3.x through 6.x. PostgreSQL, MySQL, SQL Server.

Variant phrasing: P3006 mentioning permission denied for database

The shadow database user cannot do what the migration asks. Grant the permission on the shadow database or remove the privileged statement from the migration.

Why it happens

Before applying a migration for real, Prisma replays it on a temporary empty shadow database to validate it. Anything that assumes a non-empty database, special permissions, or extensions not present there fails the replay, even though the same SQL worked on your lived-in dev database.

Edge cases

• SHADOW_DATABASE_URL unset: Prisma creates the shadow database automatically, but on some providers you must supply one explicitly.
• Editing a migration that already applied to production is forbidden; only fix migrations that have never left your machine.
• If the statement is genuinely needed and shadow-hostile, some teams set shadowDatabaseUrl to a database where they pre-install the extension.