Prisma P2005 occurs when data in your database doesn't match the type defined in your Prisma schema. This type mismatch prevents Prisma from reading or updating records. Fix it by aligning your database values with your schema definition or adjusting your schema to match the actual data.
The P2005 error indicates a type validation failure between your database and Prisma schema. When Prisma tries to read data from the database, it validates each field's value against the type specified in your schema. If the stored value doesn't conform to that type—such as a string in an integer field, null in a non-nullable field, or a mismatched foreign key type—Prisma raises this error. This is a runtime error that occurs during query execution, not at schema validation time. It typically means your database has drifted from your schema definition, or introspected types don't match the actual stored data.
The P2005 error message includes the field name and the problematic value. Extract this information from the error:
P2005: The value "abc123" stored in the database for the field "userId" is invalid for the field's typeIn this example, the field userId contains "abc123" when it should contain an integer.
Open your schema.prisma file and find the model containing the problematic field. Verify the field type:
model User {
id Int @id @default(autoincrement())
email String @unique
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
title String
userId Int // This is defined as Int
user User @relation(fields: [userId], references: [id])
}Note the exact type declaration (Int, String, DateTime, etc.) and whether it's nullable (?).
Connect directly to your database and inspect the column type:
PostgreSQL:
\d table_name;
-- or
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_name = 'your_table';MySQL:
DESCRIBE your_table;
-- or
SHOW COLUMNS FROM your_table;Compare the database type (INT, VARCHAR, TIMESTAMP) with your Prisma schema type.
Query the specific record that's causing the error to see what's actually stored:
PostgreSQL:
SELECT id, "userId", typeof("userId")
FROM "Post"
WHERE "userId" = 'abc123' OR "userId" IS NULL;MySQL:
SELECT id, userId, TYPEOF(userId)
FROM Post
WHERE userId = 'abc123' OR userId IS NULL;This helps you understand if the issue is null values, wrong data types, or incorrect stored data.
If your Prisma schema is correct and the database data is wrong, update the records:
For integer fields with string values:
UPDATE "Post" SET "userId" = CAST("userId" AS INTEGER) WHERE "userId" ~ '^[0-9]+$';For null values in non-nullable fields:
UPDATE "Post" SET "userId" = 1 WHERE "userId" IS NULL;For foreign key type mismatches:
First ensure the parent table ID type matches. If users.id is BIGINT but posts.userId is INT, update posts:
ALTER TABLE "Post" MODIFY COLUMN "userId" BIGINT;After manual database modifications, regenerate your Prisma client:
npx prisma generateIf your database data is correct but the schema is wrong, modify your schema:
// If the field should be nullable
model Post {
id Int @id @default(autoincrement())
title String
userId Int? // Now nullable
user User? @relation(fields: [userId], references: [id])
}
// If the field should be a different type
model Post {
id Int @id @default(autoincrement())
title String
userId String // Changed from Int to String
user User @relation(fields: [userId], references: [id])
}
// If the field should support larger numbers
model Post {
id Int @id @default(autoincrement())
title String
userId BigInt // Changed from Int to BigInt
user User @relation(fields: [userId], references: [id])
}Run a migration to apply schema changes:
npx prisma migrate dev --name fix_userid_typeIf you're unsure which is correct, let Prisma detect the actual database schema:
npx prisma db pullThis introspects your database and updates your schema to match. Review the changes carefully:
git diff prisma/schema.prismaIf the changes look correct, regenerate your client:
npx prisma generateAfter fixing the type mismatch, test that queries work:
const post = await prisma.post.findUnique({
where: { id: 1 },
include: { user: true },
});
console.log(post); // Should not throw P2005If the error persists, check for:
- Other fields in the model with type mismatches
- Nested relations with type mismatches
- Unsupported database types that need the @db.* unsupported attribute
Relation field type mismatches are particularly tricky. If you have a One-to-Many relationship, the foreign key scalar field (userId) must have the same type as the referenced primary key (id). If User.id is BIGINT, Post.userId must also be BIGINT.
Unsupported database types like PostgreSQL's polygon or geometry don't have Prisma equivalents. Use the @db.Unsupported("polygon") attribute to represent them without breaking your schema.
Introspection caveats: When you run prisma db pull on a database with stored procedures or triggers that modify column types, the introspection might not capture the full picture. Always review and test introspected schemas.
Prevention: Always validate data before inserting via Prisma. Use input validation libraries like Zod to ensure types match your schema. Keep your schema in sync with migrations rather than making manual database changes.
P6005: Invalid parameters (Pulse)
How to fix "P6005: Invalid parameters (Pulse)" in Prisma
P2011: Null constraint violation on the field
How to fix "P2011: Null constraint violation" in Prisma
P2009: Failed to validate the query: {validation_error}
How to fix "P2009: Failed to validate the query" in Prisma
P2007: Data validation error
How to fix "P2007: Data validation error" in Prisma
P1013: The provided database string is invalid
The provided database string is invalid