This Prisma error occurs when your schema references a model whose underlying database table has not been created yet. The fix involves applying pending migrations or synchronizing your schema with the database.
The P1014 error in Prisma indicates a critical mismatch between your Prisma schema file and the actual state of your database. When you define a model in your schema.prisma file, Prisma expects a corresponding table to exist in the database. This error is thrown when Prisma Client or Prisma Migrate attempts to access or reference a model, but the underlying database table is missing. This error commonly occurs during migration operations, particularly when using the shadow database feature in Prisma Migrate. The shadow database is a temporary database that Prisma uses to detect schema drift and validate migrations. If the shadow database doesn't contain the expected tables, or if your migration files are out of order, P1014 will be thrown. Understanding this error is essential for maintaining database schema consistency across development, staging, and production environments. The error message usually includes the specific model name that's causing the issue, making it easier to identify which table is missing.
First, check your schema.prisma file to confirm the model definitions are correct:
// Example: Check that your model is properly defined
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
}Ensure the model causing the error is actually defined in your schema and spelled correctly.
The most common fix is to apply your migrations to create the missing database tables:
# For development environments
npx prisma migrate dev
# For production environments (applies migrations without prompts)
npx prisma migrate deployThis will create all tables defined in your schema that don't yet exist in the database. If you're using db push instead of migrations:
npx prisma db pushThis syncs your schema directly to the database without creating migration files.
If you have multiple migration files, ensure they're in the correct chronological order. Each migration should build upon previous migrations:
# List your migrations directory
ls -la prisma/migrations/Migration folders are timestamped. If you see a migration that modifies a table (e.g., ALTER TABLE) before the migration that creates it (e.g., CREATE TABLE), you have an ordering issue.
To fix:
1. Delete the problematic migration files
2. Reset your database: npx prisma migrate reset
3. Recreate migrations in the correct order: npx prisma migrate dev --name your_migration_name
If the shadow database is causing issues, you can force Prisma to recreate it:
# This resets your development database and recreates the shadow database
npx prisma migrate reset
# Then apply migrations fresh
npx prisma migrate devWarning: migrate reset will delete all data in your development database. Only use this in development environments.
Check if the migration tracking table exists in your database:
-- For PostgreSQL
SELECT * FROM _prisma_migrations;
-- For MySQL
SHOW TABLES LIKE '_prisma_migrations';If this table is missing or in the wrong schema (PostgreSQL), Prisma cannot track which migrations have been applied. To fix:
# Recreate the migrations table
npx prisma migrate resolve --applied <migration_name>For PostgreSQL with custom schemas, ensure your schema.prisma includes:
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
schemas = ["public", "your_custom_schema"]
}After fixing your migrations and database state, always regenerate your Prisma Client:
npx prisma generateThis ensures your application code has the latest type definitions matching your database schema. Restart your development server after generating to pick up the changes.
Migration File Conflicts: If you're working in a team and multiple developers create migrations simultaneously, you may encounter P1014 when pulling changes. Always coordinate schema changes and resolve migration conflicts by creating a new migration that reconciles the differences.
Production Deployments: Never use prisma migrate dev in production. Always use prisma migrate deploy which applies migrations without interactive prompts and doesn't require a shadow database.
Database Provider Differences: Some database providers (like PlanetScale) don't support Prisma Migrate because they use their own schema management. In these cases, use prisma db push instead or rely on the provider's migration tools.
Prisma Studio Considerations: If you manually delete tables using Prisma Studio or a database client, but don't update your schema, you'll encounter P1014. Always keep your schema.prisma file as the source of truth and use migrations for all schema changes.
Shadow Database Requirements: The shadow database must be accessible and have the same permissions as your main database. If you're in a restricted environment (like some CI/CD pipelines), you may need to disable shadow database checks with the --skip-seed flag or provide a separate shadow database URL.
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