This Prisma error occurs when your schema references a column that doesn't exist in your database. It typically indicates a mismatch between your Prisma schema and the actual database structure, often caused by failed migrations, manual database changes, or schema drift.
The P2022 error indicates that Prisma is trying to query or manipulate a column that doesn't exist in your database. This is a schema synchronization issue where your Prisma schema file defines a field, but the corresponding column hasn't been created in the database (or has been deleted). This error commonly occurs during CRUD operations when Prisma Client attempts to access a field that's defined in your schema.prisma file but missing from the actual database table. Unlike some errors that only appear during migrations, P2022 can surface during runtime queries if your database state diverges from your schema definition. The root cause is almost always a disconnect between three sources of truth: your Prisma schema file, your migration history, and the actual database structure. When these fall out of sync, Prisma's query engine cannot generate valid SQL for the database's current state.
First, identify which column is missing and confirm the mismatch:
# Check migration status
npx prisma migrate statusThis will show if there are pending migrations or drift between your schema and database. Look for messages like "Database schema is not in sync with your migration history."
You can also inspect your database directly:
# For PostgreSQL
psql -d your_database -c "\d+ your_table_name"
# For MySQL
mysql -u user -p -e "DESCRIBE your_table_name;" your_databaseCompare the actual database columns with the fields in your schema.prisma file.
If you added fields to your schema but haven't migrated, create and apply a migration:
# Create migration for schema changes
npx prisma migrate dev --name add_missing_columnsThis will:
1. Generate SQL to create the missing columns
2. Apply the migration to your database
3. Update your migration history
For production environments:
npx prisma migrate deployIf you prefer not to use migrations (development only):
npx prisma db pushIf your database was modified manually, introspect to sync your schema:
# Pull current database schema into schema.prisma
npx prisma db pullThis updates your Prisma schema to match the database. Warning: This overwrites your schema.prisma file, so review changes carefully.
After introspection, you may need to baseline your migration history:
# Create a baseline migration without applying it
npx prisma migrate diff \
--from-empty \
--to-schema-datamodel schema.prisma \
--script > baseline.sql
# Mark it as applied
npx prisma migrate resolve --applied "0_baseline"If you're in development and can afford to lose data, reset everything:
# Reset database and apply all migrations from scratch
npx prisma migrate resetThis will:
1. Drop the database
2. Create a fresh database
3. Apply all migrations in order
4. Run your seed script (if configured)
WARNING: This deletes all data. Only use in development environments.
After applying migrations, regenerate your Prisma Client:
npx prisma generateThen verify the fix:
# Check migration status again
npx prisma migrate statusYou should see "Database schema is up to date!" with no pending migrations or drift.
Test your application to ensure queries work:
// Test the previously failing operation
const result = await prisma.yourModel.create({
data: {
// Include the field that was causing P2022
previouslyMissingColumn: 'test value',
},
});
console.log('Success:', result);Understanding Schema Drift
Schema drift occurs when your database schema diverges from your migration history. This can happen through:
- Manual ALTER TABLE statements
- Using db push instead of migrations
- Running migrations out of order
- Hotfixes applied directly to production
To prevent drift in production, use a strict workflow: all schema changes must go through Prisma Migrate with version-controlled migration files.
The referentialIntegrity Issue
A known bug (GitHub issue #11792) causes P2022 when using referentialIntegrity = "prisma" with models that have non-standard primary key names (not "id"). If you encounter this:
// Problematic
model User {
userId String @id @default(uuid())
posts Post[]
}
model Post {
postId String @id @default(uuid())
userId String
user User @relation(fields: [userId], references: [userId])
}Consider switching to database-level referential integrity or renaming primary keys to "id".
@map and @@map Attributes
When using column mapping, ensure your database column names match:
model User {
fullName String @map("full_name") // Database column is "full_name"
}If the database column doesn't match the @map value, you'll get P2022.
Production Migration Strategy
For zero-downtime deployments:
1. Add new nullable columns first
2. Deploy application code that populates them
3. Run a data migration to fill existing rows
4. Make columns non-nullable in a subsequent migration
5. Remove old columns only after confirming the new ones work
This prevents P2022 errors during rolling deployments where old code expects old columns.
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