This error occurs during prisma migrate reset when both the primary and fallback database cleanup methods fail. It typically indicates permission issues or database constraints preventing Prisma from fully resetting your development database.
The P3016 error occurs when Prisma Migrate attempts to reset your database during development but encounters failures in both the standard cleanup process and the fallback mechanism. When you run `prisma migrate reset`, Prisma tries to drop all database objects (tables, views, functions, etc.) to give you a clean slate before reapplying migrations. If the primary method fails—for example, due to active connections or locked objects—Prisma attempts a fallback method that manually removes individual database objects. The P3016 error means both approaches failed. The error message includes an "inner error" that reveals the underlying database-specific issue, such as insufficient permissions, foreign key constraints, or active connections preventing object deletion.
The P3016 error includes an "inner error" that reveals the root cause. Run the reset command again and examine the full error output:
npx prisma migrate resetLook for the text after "Original error:" which might show:
- Permission denied errors (check database user privileges)
- "Cannot drop X because other objects depend on it" (check foreign keys)
- "Database is being accessed by other users" (close connections)
The inner error determines which subsequent steps apply to your situation.
Ensure your Prisma database user has sufficient privileges to drop and recreate schema objects.
For PostgreSQL:
-- Grant all privileges on the database
GRANT ALL PRIVILEGES ON DATABASE your_db TO your_user;
-- Or make the user a superuser (development only)
ALTER USER your_user WITH SUPERUSER;For MySQL:
GRANT ALL PRIVILEGES ON your_db.* TO 'your_user'@'localhost';
FLUSH PRIVILEGES;For SQLite: Verify the process has write permissions on the database file and its directory:
ls -la prisma/*.db
chmod 644 prisma/dev.dbActive connections can prevent Prisma from dropping the database or schema.
For PostgreSQL, terminate connections:
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'your_database_name'
AND pid <> pg_backend_pid();For MySQL:
SHOW PROCESSLIST;
-- Then kill specific connections
KILL <process_id>;Also ensure you've closed:
- Database GUI tools (TablePlus, pgAdmin, MySQL Workbench)
- Other terminals running Prisma Studio or database queries
- Application servers with active database connections
If the automated reset continues failing, manually drop and recreate the database:
For PostgreSQL:
# Connect as superuser
psql postgres
# Drop and recreate
DROP DATABASE your_db;
CREATE DATABASE your_db;
GRANT ALL PRIVILEGES ON DATABASE your_db TO your_user;For MySQL:
DROP DATABASE your_db;
CREATE DATABASE your_db;For SQLite, simply delete the file:
rm prisma/dev.dbThen run migrations fresh:
npx prisma migrate devSometimes the error occurs during the seeding phase after reset. Skip seeding to isolate the problem:
npx prisma migrate reset --skip-seedIf this succeeds, the issue is in your seed script rather than the reset mechanism. Run the seed separately to debug:
npx prisma db seedPrisma uses a temporary "shadow database" during development to detect schema drift. If shadow database creation fails, it can trigger P3016.
Verify the shadow database URL in your schema:
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
shadowDatabaseUrl = env("SHADOW_DATABASE_URL") // Optional but recommended
}Ensure your user can create databases:
-- PostgreSQL
ALTER USER your_user CREATEDB;Or explicitly provide a shadow database URL in your .env:
SHADOW_DATABASE_URL="postgresql://user:pass@localhost:5432/shadow_db"Understanding Prisma's Reset Mechanism:
When you run prisma migrate reset, Prisma attempts to clean the database using a two-stage approach:
1. Primary method: Drop the entire database or schema (PostgreSQL CASCADE drop)
2. Fallback method: If the primary method fails, manually enumerate and drop individual objects (tables, views, sequences, etc.)
The P3016 error indicates both stages failed, which is unusual and typically points to environmental issues rather than Prisma bugs.
Database-Specific Considerations:
- PostgreSQL: Template databases (template0, template1) cannot be reset. Ensure your DATABASE_URL doesn't point to a template. Also, extensions like PostGIS may require superuser privileges to drop.
- MySQL: The SUPER privilege may be required to drop certain system tables or views created by other users.
- SQLite: File permissions are critical. The directory containing the SQLite file must be writable for Prisma to delete and recreate it.
Production Safety:
Never run migrate reset in production—it destroys all data. Use migrate deploy instead, which applies pending migrations without resetting. The reset command is strictly for development workflows.
Alternative: Fresh Migration Baseline:
If you consistently encounter reset issues and don't need migration history, you can create a fresh baseline:
# Delete existing migrations
rm -rf prisma/migrations
# Create new baseline
npx prisma migrate dev --name initThis is destructive to migration history but gives you a clean start.
P1013: The provided database string is invalid
The provided database string is invalid
P1000: Authentication failed against database server
Authentication failed against database server
P1010: User was denied access on the database
How to fix "P1010: User was denied access on the database" in Prisma
P5008: Usage exceeded, upgrade your plan (Accelerate)
How to fix "Usage exceeded, upgrade your plan" in Prisma Accelerate
P3021: Foreign keys cannot be created on this database
How to fix 'P3021: Foreign keys cannot be created on this database' in Prisma