How to fix P3022: Direct execution of DDL (Data Definition Language) SQL statements is disabled on this database. in Prisma

PrismaINTERMEDIATEMEDIUMUpdated Dec 18, 2025· 96 views

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.

Quick fix

Fixes P3022

npx prisma db push
  1. Switch to prisma db push for PlanetScale development
  2. Use PlanetScale branch workflow for production changes
  3. Configure Prisma schema for PlanetScale compatibility
  4. Disable Prisma Migrate in production environments
prisma — error
npx prisma db push
P3022: Direct execution of DDL (Data Definition Language) SQL statements is disabled on this database.
shell
npx prisma db push

What this error means

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.

Typical symptoms

  • Running "prisma migrate dev" or "prisma migrate deploy" fails with P3022 error
  • Error message states "Direct execution of DDL statements is disabled"
  • Migration works locally but fails when deployed to cloud database
  • PlanetScale or Vitess returns "ERROR HY000 (1105): direct DDL is disabled"
  • Schema changes succeed on development branches but fail on production branches

Common causes

  1. Attempting to run Prisma migrations directly on a PlanetScale production branch
  2. Using "prisma migrate" commands on databases with DDL restrictions enabled
  3. Not configuring Prisma to use the recommended workflow for branch-based databases
  4. Trying to modify schema on main database branch instead of using deploy requests
  5. CI/CD pipeline running migrations without proper branch workflow setup

How to fix "P3022: Direct execution of DDL (Data Definition Language) SQL statements is disabled on this database."

1Switch to prisma db push for PlanetScale development

If you're in active development, use prisma db push instead of prisma migrate dev. This command pushes schema changes without creating migration files:

bash
npx prisma db push

This 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.

2Use PlanetScale branch workflow for production changes

For production deployments, follow the PlanetScale branch-based workflow:

1. Create a development branch in PlanetScale dashboard:

bash
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:

bash
npx prisma db push

4. Create a deploy request in PlanetScale to merge changes to production:

bash
pscale deploy-request create <database-name> <branch-name>

5. Review and deploy the request through the PlanetScale dashboard

3Configure Prisma schema for PlanetScale compatibility

Update your schema.prisma to work with PlanetScale's limitations:

prisma
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.

4Disable Prisma Migrate in production environments

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:

bash
# In your deployment script
if [ "$DATABASE_PROVIDER" != "planetscale" ]; then
  npx prisma migrate deploy
fi

This prevents the P3022 error during automated deployments.

5Consider alternative database providers if migrations are critical

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.

Advanced notes

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

Frequently asked questions

What does "P3022" mean?
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.
How do I fix "P3022"?
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.
What causes "P3022"?
Attempting to run Prisma migrations directly on a PlanetScale production branch Using "prisma migrate" commands on databases with DDL restrictions enabled Not configuring Prisma to use the recommended workflow for branch-based databases
Is the "P3022" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading