How to fix P3005: The database schema is not empty in Prisma

PrismaINTERMEDIATEHIGHUpdated Dec 22, 2025· 135 views

Prisma throws P3005 when you run an initial migration against a database that already contains tables. The CLI refuses to run until you either baseline the current schema or start from a clean database. Resolve the existing schema before rerunning Prisma Migrate so future migrations have a recorded history.

Quick fix

Fixes P3005: The database schema is not empty

npx prisma migrate status

# Then list tables (PostgreSQL example)
psql "$DATABASE_URL" -c 'dt'

# Or query information_schema (MySQL example)
mysql --execute 'SELECT table_name FROM information_schema.tables WHERE table_schema = DATABASE();'
  1. Inspect the current schema before migrating
  2. Baseline the existing schema
  3. Start from a clean database if possible
  4. Protect the baseline for future environments
prisma — error
npx prisma migrate status
# Then list tables (PostgreSQL example)
psql "$DATABASE_URL" -c 'dt'
# Or query information_schema (MySQL example)
mysql --execute 'SELECT table_name FROM information_schema.tables WHERE table_schema = DATABASE();'
P3005: The database schema is not empty

What this error means

Prisma Migrate enforces P3005 on the very first migration to protect existing databases. When the CLI detects tables, views, or other objects but cannot find a recorded migration history, it stops with "The database schema is not empty" so you do not accidentally overwrite or misalign production data. This usually happens when you try to apply Prisma migrations to a legacy database, a restore from production, or any schema that was created before the current migration pipeline existed. Even if you generated the same schema with `prisma db push`, the migration engine still expects a clean slate for the first migration so it can record the initial state inside `_prisma_migrations`. The safest path forward is to treat the current schema as a baseline: introspect or inspect it so Prisma knows what the database already looks like, record that baseline migration as applied, and then run new migrations on top of that. Alternatively, work against an empty clone of the database so the CLI can bootstraps migrations without confusion.

Typical symptoms

  • Prisma migrate commands immediately fail with "P3005: The database schema is not empty".
  • The CLI never generates SQL because it refuses to run migrations on a schema that already has tables.
  • _prisma_migrations table is empty or missing while other tables already exist.
  • CI/CD pipelines stall at the migration step with the same error every run.
  • New migrations remain in "Pending" state because the first migration cannot be applied.

Common causes

  1. Running Prisma Migrate against a legacy database that already contains tables.
  2. Pointing `prisma migrate dev` or `deploy` at the wrong environment (production/staging) instead of a fresh database.
  3. Restoring a dump that includes schema objects before running the first migration.
  4. Using `prisma db push` or manual SQL to create the schema and then attempting migrations without baselining.
  5. Sharing one database between multiple teams or tools so it is never empty before Prisma runs.

How to fix "P3005: The database schema is not empty"

1Inspect the current schema before migrating

Confirm that the database already has objects and that Prisma has no recorded baseline yet:

bash
npx prisma migrate status

# Then list tables (PostgreSQL example)
psql "$DATABASE_URL" -c 'dt'

# Or query information_schema (MySQL example)
mysql --execute 'SELECT table_name FROM information_schema.tables WHERE table_schema = DATABASE();'

Look for existing tables and for the absence of an applied migration inside _prisma_migrations. This explains why Prisma stops with P3005.

2Baseline the existing schema

If you want to keep the current schema and data, tell Prisma about it before generating new migrations:

bash
# Introspect the schema so your Prisma schema matches production
npx prisma db pull

# Create a migration that captures the current state without applying it
npx prisma migrate dev --create-only --name init

# Mark that migration as already applied in the database
npx prisma migrate resolve --applied init

Now the database has an entry in _prisma_migrations, and future prisma migrate dev runs will build on top of the baseline instead of re-running it.

3Start from a clean database if possible

If you can recreate the database, drop the existing schema and let Prisma run the first migration on an empty database:

bash
npx prisma migrate reset --force

# Or manually drop and recreate schemas:
psql "$DATABASE_URL" -c 'DROP SCHEMA public CASCADE; CREATE SCHEMA public;'
npx prisma migrate dev

Always back up your data first. Resetting is safest for development copies, not production.

4Protect the baseline for future environments

After baselining, keep migrations deterministic:

bash
npx prisma migrate status
npx prisma migrate deploy   # for production

Share the baseline migration with teammates, and avoid running prisma migrate dev against shared or production databases without a dedicated migration history. If your workflow still needs to refresh dev copies often, script the baseline steps so they repeat reliably.

Advanced notes

Deploy-time behavior: Prisma Migrate always runs the baseline migration only once per database. Use prisma migrate deploy on environments where you have already resolved the baseline, and Prisma will skip the resolved migration automatically.

Shadow database: When you run prisma migrate dev, Prisma also compares the schema against a shadow database. Make sure the shadow URL points to an empty schema, otherwise the comparison may also trigger P3005-like complaints.

Prisma db push: db push can sync your schema to an existing database, but it does not touch migration history. Run the baseline steps before switching to migration-based workflows.

Frequently asked questions

What does "P3005: The database schema is not empty" mean?
Prisma Migrate enforces P3005 on the very first migration to protect existing databases. When the CLI detects tables, views, or other objects but cannot find a recorded migration history, it stops with "The database schema is not empty" so you do not accidentally overwrite or misalign production data. This usually happens when you try to apply Prisma migrations to a legacy database, a restore from production, or any schema that was created before the current migration pipeline existed.
How do I fix "P3005: The database schema is not empty"?
Prisma throws P3005 when you run an initial migration against a database that already contains tables. The CLI refuses to run until you either baseline the current schema or start from a clean database. Resolve the existing schema before rerunning Prisma Migrate so future migrations have a recorded history.
What causes "P3005: The database schema is not empty"?
Running Prisma Migrate against a legacy database that already contains tables. Pointing prisma migrate dev or deploy at the wrong environment (production/staging) instead of a fresh database. Restoring a dump that includes schema objects before running the first migration.
Is the "P3005: The database schema is not empty" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading