How to fix P1010: User was denied access on the database in Prisma

PrismaINTERMEDIATEHIGHUpdated Dec 29, 2025· 244 views

The Prisma P1010 error indicates that the database user lacks the required permissions to perform operations, typically during migration or connection initialization. This usually occurs due to insufficient CREATE DATABASE privileges for shadow databases or incorrect connection credentials. Resolving it requires granting proper database permissions or configuring a shadow database URL.

Quick fix

Fixes P1010: User was denied access on the database

-- Connect as a superuser (usually 'postgres')
ALTER USER your_username CREATEDB;
  1. Verify your database connection credentials
  2. Grant CREATE DATABASE privileges to your user
  3. Configure a shadow database URL (Alternative approach)
  4. For PostgreSQL with proxies: Disable channel binding
prisma — error
-- Connect as a superuser (usually 'postgres')
ALTER USER your_username CREATEDB;
P1010: User was denied access on the database

What this error means

The P1010 error in Prisma means that the user specified in your DATABASE_URL connection string has been denied access to perform operations on the database. This is a permissions-level error rather than a simple authentication failure (like P1000). Prisma Migrate requires special privileges to function properly because it creates a temporary shadow database internally for validation and planning purposes. If your database user doesn't have the CREATE DATABASE permission, Prisma will fail with the P1010 error. This error can manifest in different ways: - "User `username` was denied access on the database `database_name`" (permission denied) - "User `username` was denied access on the database `database.public`" (schema-specific permissions) The error is critical because without proper permissions, you cannot run migrations or perform database operations that Prisma requires.

Typical symptoms

  • Prisma migrate dev or migrate deploy commands fail with P1010 error
  • Prisma Client initialization fails during deployment
  • Error occurs even though the database connection string appears correct
  • Manual database queries work fine, but Prisma operations fail
  • Shadow database creation fails with permission denied errors
  • Error appears to be permissions-related rather than connectivity-related

Common causes

  1. The database user lacks CREATE DATABASE privileges needed for the shadow database
  2. The connection uses a read-only database user or limited-privilege account
  3. Channel binding security mechanism is blocking connections through proxies (PostgreSQL)
  4. Database role or user doesn't have proper schema permissions
  5. Shadow database configuration is missing for restricted environments
  6. Using a database proxy or cache (like PolyScale) without disabling channel binding
  7. Incorrect role hierarchy or privilege inheritance in the database system

How to fix "P1010: User was denied access on the database"

1Verify your database connection credentials

First, confirm that your DATABASE_URL is correct and the credentials are valid:

1. Check your .env file for the DATABASE_URL
2. Verify the format is correct for your database type:
 - PostgreSQL: postgresql://username:password@host:port/database
 - MySQL: mysql://username:password@host:port/database
3. Test the connection manually using a database client:
 - PostgreSQL: psql "postgresql://username:password@host:port/database"
 - MySQL: mysql -u username -p -h host database

If manual connection works but Prisma fails, the issue is likely permissions, not credentials.

2Grant CREATE DATABASE privileges to your user

The most common cause of P1010 is that the database user lacks CREATE DATABASE privileges. Connect to your database as an admin user and grant these permissions:

For PostgreSQL:

sql
-- Connect as a superuser (usually 'postgres')
ALTER USER your_username CREATEDB;

For MySQL:

sql
-- Connect as root or admin
GRANT ALL PRIVILEGES ON *.* TO 'your_username'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

For a more restrictive MySQL setup:

sql
GRANT CREATE, ALTER, DROP, SELECT, INSERT, UPDATE, DELETE ON your_database.* TO 'your_username'@'localhost';
FLUSH PRIVILEGES;

After granting privileges, try running your Prisma commands again.

3Configure a shadow database URL (Alternative approach)

If you cannot grant CREATE DATABASE privileges (e.g., in managed database services), configure a separate shadow database:

Edit your prisma/schema.prisma:

prisma
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  shadowDatabaseUrl = env("SHADOW_DATABASE_URL")
}

Then add to your .env file:

bash
DATABASE_URL="postgresql://username:password@host:port/main_database"
SHADOW_DATABASE_URL="postgresql://username:password@host:port/shadow_database"

The shadow database must exist and be empty. Create it with:

sql
-- PostgreSQL
CREATE DATABASE shadow_database;

-- MySQL
CREATE DATABASE shadow_database;

This tells Prisma to use a separate database for its internal operations instead of trying to create one.

4For PostgreSQL with proxies: Disable channel binding

If you're using a database proxy or cache like PolyScale, AWS RDS Proxy, or similar, disable PostgreSQL channel binding:

Modify your DATABASE_URL to include channel_binding=disable:

bash
postgresql://username:password@host:port/database?channel_binding=disable

Channel binding is a security feature that prevents man-in-the-middle attacks, but it cannot work through proxies. Disabling it allows the proxy to act as a middleman while maintaining encryption through SSL/TLS.

Verify the full connection string:

bash
postgresql://user:pass@proxy-host:port/db?channel_binding=disable
5Check database schema permissions (PostgreSQL)

If the user has basic database access but cannot access specific schemas:

sql
-- Grant schema usage permissions
GRANT USAGE ON SCHEMA public TO your_username;

-- Grant all table permissions in the schema
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO your_username;

-- Grant sequence permissions (for auto-incrementing IDs)
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO your_username;

-- Make this the default for future objects
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON TABLES TO your_username;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON SEQUENCES TO your_username;

This is especially important after restoring a database from a backup.

6Use prisma migrate deploy for read-only users (Production)

In production environments with restricted users, use prisma migrate deploy instead of prisma migrate dev:

bash
# For development (requires shadow database or CREATE privileges)
npx prisma migrate dev --name add_users_table

# For production (no shadow database needed, just applies pending migrations)
npx prisma migrate deploy

prisma migrate deploy doesn't require shadow database creation, so it works with more restrictive user permissions. It applies pre-planned migrations without attempting to create temporary databases.

You can run your schema planning locally or in CI/CD, then deploy only the final migrations to production with a read-only-ish user.

7Verify the correct database is being targeted

Sometimes P1010 occurs because your connection string is pointing to a database you don't have permissions for:

1. Verify you're connecting to the intended database:
 - Check the database name in your DATABASE_URL
 - List available databases you have access to:

PostgreSQL:

bash
psql -l

MySQL:

bash
mysql -u username -p -e "SHOW DATABASES;"

2. If connecting to a cloud database service:
 - Verify the connection string from your provider (Railway, Vercel, AWS RDS, Azure, etc.)
 - Check if your cloud provider has set default users with limited privileges
 - Look for documentation on how to grant Prisma privileges

3. Make sure you're not accidentally connecting to the wrong environment:
 - Verify .env file is loading the correct DATABASE_URL
 - Check for variable name conflicts (DATABASE_URL vs DB_URL vs DATABASE_CONNECTION_URL)

Advanced notes

Cloud Database Services: Different platforms handle permissions differently:
- Railway: Provides a database with full privileges by default
- AWS RDS: May require parameter group modifications; check RDS documentation
- Azure Database: Check the "Connection security" settings and firewall rules
- Heroku Postgres: Connection users typically have necessary privileges; check Heroku Dashboard
- Vercel: Follows Railway or provides direct connection strings

Environment-Specific Configurations: Consider using different database users for different environments:
- Development: Full privileges (CREATE DATABASE, DROP, etc.)
- Staging: Sufficient privileges but more restricted
- Production: Minimal privileges (SELECT, INSERT, UPDATE, DELETE on specific tables only)

For production, you might use separate credentials for migrations (with more privileges) and application runtime (with restricted privileges).

Rate Limiting and Connection Pooling: Some connection pooling solutions (PgBouncer, pgpool) may not support all authentication methods. Ensure your pool configuration supports the authentication mechanism your user requires.

Shadow Database Best Practices: When using shadowDatabaseUrl:
- Keep it truly empty and separate from production
- Use the same database system as your main database
- Ensure the same user can access both databases
- Clean it up regularly as Prisma will create/drop tables during development
- Never point shadowDatabaseUrl to your production database

Frequently asked questions

What does "P1010: User was denied access on the database" mean?
The P1010 error in Prisma means that the user specified in your DATABASE_URL connection string has been denied access to perform operations on the database. This is a permissions-level error rather than a simple authentication failure (like P1000). Prisma Migrate requires special privileges to function properly because it creates a temporary shadow database internally for validation and planning purposes.
How do I fix "P1010: User was denied access on the database"?
The Prisma P1010 error indicates that the database user lacks the required permissions to perform operations, typically during migration or connection initialization. This usually occurs due to insufficient CREATE DATABASE privileges for shadow databases or incorrect connection credentials. Resolving it requires granting proper database permissions or configuring a shadow database URL.
What causes "P1010: User was denied access on the database"?
The database user lacks CREATE DATABASE privileges needed for the shadow database The connection uses a read-only database user or limited-privilege account Channel binding security mechanism is blocking connections through proxies (PostgreSQL)
Is the "P1010: User was denied access on the database" 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