This error occurs when trying to run Prisma migrations on cloud databases like PlanetScale or Vitess that restrict direct schema changes on production branches. These platforms enforce a branch-based workflow where schema changes must be made on development branches and deployed through merge/deploy requests.
The P3022 error is thrown when Prisma Migrate attempts to execute DDL (Data Definition Language) statements—like CREATE TABLE, ALTER TABLE, or DROP TABLE—on a database that has disabled direct DDL execution. This restriction is common on managed database platforms like PlanetScale and Vitess-based systems. These platforms enforce a git-style workflow for schema changes to prevent accidental modifications to production data. Instead of allowing direct schema changes on your main/production branch, they require you to create development branches, test your changes there, and then deploy them through a controlled review process. This safeguard ensures that schema changes are versioned, reviewed, and can be rolled back if needed—similar to how code changes go through pull requests before merging to production.
If you're in active development, use prisma db push instead of prisma migrate dev. This command pushes schema changes without creating migration files:
npx prisma db pushThis works on development branches and is the recommended approach for PlanetScale during development. Note that db push doesn't generate migration history, so it's best for prototyping.
For production deployments, follow the PlanetScale branch-based workflow:
1. Create a development branch in PlanetScale dashboard:
pscale branch create <database-name> <branch-name>2. Update your DATABASE_URL to point to the development branch
3. Make schema changes using prisma db push:
npx prisma db push4. Create a deploy request in PlanetScale to merge changes to production:
pscale deploy-request create <database-name> <branch-name>5. Review and deploy the request through the PlanetScale dashboard
Update your schema.prisma to work with PlanetScale's limitations:
datasource db {
provider = "mysql"
url = env("DATABASE_URL")
relationMode = "prisma" // Required for PlanetScale
}PlanetScale doesn't support foreign key constraints, so setting relationMode = "prisma" tells Prisma to handle referential integrity at the application level instead of the database level.
For production deployments on PlanetScale, avoid using Prisma Migrate commands. Instead:
1. Remove migration commands from your deployment scripts
2. Rely on PlanetScale's deploy request system for schema changes
3. Use environment-specific checks in CI/CD:
# In your deployment script
if [ "$DATABASE_PROVIDER" != "planetscale" ]; then
npx prisma migrate deploy
fiThis prevents the P3022 error during automated deployments.
If your workflow heavily depends on traditional migration tools, consider database providers that support direct DDL:
- Neon: PostgreSQL-compatible with full migration support
- Supabase: PostgreSQL with traditional migration workflows
- Railway: Supports PostgreSQL/MySQL with standard migrations
- AWS RDS: Full control over migration execution
Migrate your data using tools like pgloader or database-specific export/import utilities. This allows you to use prisma migrate deploy without restrictions.
Why PlanetScale Disables Direct DDL
PlanetScale is built on Vitess, a database clustering system originally developed at YouTube. Vitess includes a configuration option enable_direct_ddl which PlanetScale sets to false for production branches. This enforces schema change safety through their branching system.
Foreign Key Trade-offs
When using relationMode = "prisma", be aware that:
- Referential integrity is enforced by Prisma Client, not the database
- Cascade deletes are handled in application code (slower for large datasets)
- You lose database-level constraints that protect against orphaned records from external queries
- This can lead to data inconsistencies if you modify data outside of Prisma
Migration File Management
If you started with traditional migrations and switch to PlanetScale:
1. Your existing migration files remain in source control as documentation
2. New changes use db push instead of generating migration files
3. Consider using prisma migrate resolve to mark existing migrations as applied
4. Some teams maintain separate migration strategies per environment
Alternative: Prisma Accelerate
For teams that want PlanetScale's performance with traditional migrations, consider:
- Using Prisma Accelerate as a connection pooler
- Deploying to a PostgreSQL database that supports migrations
- Benefiting from edge caching while keeping migration workflows intact
Deployment Branch Safety
PlanetScale's deploy request system provides:
- Schema diff previews before applying changes
- Ability to revert deployments if issues arise
- Deploy queues to prevent conflicting schema changes
- Integration with CI/CD through their CLI and API
P6005: Invalid parameters (Pulse)
How to fix "P6005: Invalid parameters (Pulse)" in Prisma
P2011: Null constraint violation on the field
How to fix "P2011: Null constraint violation" in Prisma
P2009: Failed to validate the query: {validation_error}
How to fix "P2009: Failed to validate the query" in Prisma
P2007: Data validation error
How to fix "P2007: Data validation error" in Prisma
P1013: The provided database string is invalid
The provided database string is invalid