How to fix P2022: The column `{column}` does not exist in the current database. in Prisma

PrismaINTERMEDIATEHIGHUpdated Dec 22, 2025ยท 315 views

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.

Quick fix

Fixes P2022

# Check migration status
npx prisma migrate status
  1. Verify the schema-database mismatch
  2. Generate and apply the missing migration
  3. Resolve schema drift with introspection
  4. Reset the database (development only)
prisma โ€” error
# Check migration status
npx prisma migrate status
P2022: The column `{column}` does not exist in the current database.

What this error means

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.

Typical symptoms

  • Runtime queries fail with "The column does not exist" error
  • Error occurs after adding new fields to Prisma schema without migrating
  • Operations work in development but fail in production with different database state
  • Error appears after manually modifying database schema outside Prisma
  • Issue surfaces when switching between git branches with different schema versions
  • Create or update operations fail referencing specific field names

Common causes

  1. Added a field to schema.prisma but forgot to run prisma migrate dev or prisma db push
  2. Migration failed to apply but Prisma schema was updated anyway
  3. Database schema was modified manually (ALTER TABLE) without updating Prisma schema
  4. Used prisma db pull to update schema but database is missing columns from previous state
  5. Migration history is out of sync between development and production databases
  6. Column was renamed in schema using @map but database still has old column name
  7. Database was restored from backup that predates recent schema changes
  8. Different team members applied migrations in different orders causing drift

How to fix "P2022: The column `{column}` does not exist in the current database."

1Verify the schema-database mismatch

First, identify which column is missing and confirm the mismatch:

bash
# Check migration status
npx prisma migrate status

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

bash
# For PostgreSQL
psql -d your_database -c "\d+ your_table_name"

# For MySQL
mysql -u user -p -e "DESCRIBE your_table_name;" your_database

Compare the actual database columns with the fields in your schema.prisma file.

2Generate and apply the missing migration

If you added fields to your schema but haven't migrated, create and apply a migration:

bash
# Create migration for schema changes
npx prisma migrate dev --name add_missing_columns

This will:
1. Generate SQL to create the missing columns
2. Apply the migration to your database
3. Update your migration history

For production environments:

bash
npx prisma migrate deploy

If you prefer not to use migrations (development only):

bash
npx prisma db push
3Resolve schema drift with introspection

If your database was modified manually, introspect to sync your schema:

bash
# Pull current database schema into schema.prisma
npx prisma db pull

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

bash
# 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"
4Reset the database (development only)

If you're in development and can afford to lose data, reset everything:

bash
# Reset database and apply all migrations from scratch
npx prisma migrate reset

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

5Verify the fix and regenerate Prisma Client

After applying migrations, regenerate your Prisma Client:

bash
npx prisma generate

Then verify the fix:

bash
# Check migration status again
npx prisma migrate status

You should see "Database schema is up to date!" with no pending migrations or drift.

Test your application to ensure queries work:

typescript
// 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);

Advanced notes

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:

prisma
// 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:

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

Frequently asked questions

What does "P2022" mean?
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). prisma file but missing from the actual database table.
How do I fix "P2022"?
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.
What causes "P2022"?
Added a field to schema.prisma but forgot to run prisma migrate dev or prisma db push Migration failed to apply but Prisma schema was updated anyway Database schema was modified manually (ALTER TABLE) without updating Prisma schema
Is the "P2022" 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