Paste the Prisma error.
Get the fix.

@prisma/client did not initialize yet

Error: @prisma/client did not initialize yet. Please run "prisma generate" and try to import it again.

@prisma/client is only a shell until prisma generate writes the real client for your schema. The code imported it before that ever happened on this machine or in this build.

usually because

• –The agent ran npm install prisma @prisma/client but never prisma generate
• –A fresh clone or CI build where nothing runs prisma generate
• –node_modules was cached from a build that had no schema yet

fix

1. 1.Run npx prisma generate once locally
2. 2.Add "postinstall": "prisma generate" to package.json so every install regenerates
3. 3.Make the build script prisma generate && next build

"scripts": {
  "build": "prisma generate && next build",
  "postinstall": "prisma generate"
}

Property 'x' does not exist on type 'PrismaClient'

Type error: Property 'invoice' does not exist on type 'PrismaClient<PrismaClientOptions, never, DefaultArgs>'.

The model or field exists in schema.prisma but not in the generated client TypeScript sees. The client is generated code: it only changes when prisma generate runs.

usually because

• –The agent added a model to schema.prisma and went straight to writing queries
• –The model name is singular in the schema (model Invoice) but the code uses db.invoices
• –The editor's TypeScript server still has the old types cached

fix

1. 1.Run npx prisma generate (prisma db push and prisma migrate dev also run it)
2. 2.Use the lowercase model name: model Invoice becomes db.invoice
3. 3.Restart the TypeScript server in your editor if the error stays after generating

Prisma has detected that this project was built on Vercel

Prisma has detected that this project was built on Vercel, which caches dependencies. This leads to an outdated Prisma Client because Prisma's auto-generation isn't triggered. To fix this, make sure to run the `prisma generate` command during the build process.

Vercel (and Netlify CI) reuse node_modules between builds, so the install step that would normally regenerate the client is skipped. Your deploy runs a client generated for an older schema, or none at all.

usually because

• –package.json has no postinstall or build step that runs prisma generate
• –The agent removed prisma generate from the build script while "cleaning up"

fix

1. 1.Set the build script to prisma generate && next build
2. 2.Or add "postinstall": "prisma generate"
3. 3.Redeploy (no need to clear the cache once the script runs generate)

"scripts": {
  "build": "prisma generate && next build",
  "postinstall": "prisma generate"
}

PrismaClient is unable to run in this browser environment

Error: PrismaClient is unable to run in this browser environment, or has been bundled for the browser (running in `…`).
If this is unexpected, please open an issue: https://pris.ly/prisma-prisma-bug-report

Prisma Client ended up in JavaScript that runs in the browser. It can only run on the server: it needs your database URL and a server-side engine.

usually because

• –A "use client" component imports db from lib/db.ts
• –A shared helper file imports Prisma and is also used by a Client Component
• –The agent fixed a hook error by adding "use client" to a page that queries the database

fix

1. 1.Do the query in a Server Component, Server Action or route handler, and pass plain data to the Client Component as props
2. 2.Add import "server-only" at the top of lib/db.ts, so any client import fails at build time with a clear message
3. 3.Split helpers: keep database code in files only the server imports

import "server-only";
import { PrismaClient } from "@prisma/client";

const globalForPrisma = globalThis as unknown as { prisma?: PrismaClient };
export const db = globalForPrisma.prisma ?? new PrismaClient();
if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = db;

PrismaClient is not configured to run in Edge Runtime

Error: PrismaClient is not configured to run in Edge Runtime (Vercel Edge Functions, Vercel Edge Middleware, Next.js (Pages Router) Edge API Routes, Next.js (App Router) Edge Route Handlers or Next.js Middleware). In order to run Prisma Client on edge runtime, either:
- Use Prisma Accelerate: https://pris.ly/d/accelerate
- Use Driver Adapters: https://pris.ly/d/driver-adapters

The default Prisma 6 client needs Node.js. Code that imports it is running on the Edge runtime or Cloudflare Workers, where it can't open a normal database connection.

usually because

• –export const runtime = "edge" on a route or page that queries the database
• –An old middleware.ts (Edge) that calls auth() with a Prisma adapter
• –Deploying a Node.js Next.js app to Cloudflare Workers without a driver adapter

fix

1. 1.Delete export const runtime = "edge": the Node.js runtime is the default and runs Prisma fine
2. 2.On Next.js 16, rename middleware.ts to proxy.ts: proxy runs on Node.js
3. 3.If you really need the edge or Workers, use a driver adapter (Neon, PlanetScale, D1) or Prisma Accelerate

Environment variable not found: DATABASE_URL

error: Environment variable not found: DATABASE_URL.
  -->  schema.prisma:8
   |
 7 |   provider = "postgresql"
 8 |   url      = env("DATABASE_URL")

schema.prisma reads the connection string from env("DATABASE_URL") and it isn't set where this command or server is running.

usually because

• –The agent put DATABASE_URL in .env.local: Next.js reads it, but the Prisma 6 CLI only loads .env
• –It's set locally but not in the Vercel (or other host) project settings
• –It's set for Production but not Preview deployments

fix

1. 1.For local dev, put DATABASE_URL in .env (keep it in .gitignore)
2. 2.Add it in your host's environment variables for every environment that builds or runs the app, then redeploy
3. 3.Check the spelling: the name in env("…") must match exactly

The URL must start with the protocol postgresql://

error: Error validating datasource `db`: the URL must start with the protocol `postgresql://` or `postgres://`.
  -->  schema.prisma:8

DATABASE_URL is set, but it doesn't match the provider in schema.prisma. Prisma checks the protocol before connecting.

usually because

• –provider = "postgresql" but DATABASE_URL is still file:./dev.db (or the other way round)
• –The Supabase or Neon project URL (https://…) pasted instead of the database connection string
• –Quotes or a space copied into the value in the hosting dashboard

fix

1. 1.Make the provider and the URL agree: postgresql:// for Postgres, file: for SQLite
2. 2.Copy the connection string from the database's Connect panel, not the API URL
3. 3.Paste the raw value in the dashboard, without quotes

P1001: Can't reach database server

PrismaClientInitializationError: Can't reach database server at `db.example.supabase.co:5432`

Please make sure your database server is running at `db.example.supabase.co:5432`.

Prisma couldn't open a network connection to the host and port in DATABASE_URL. Nothing about your schema or query yet: it's the network, the host or the database itself.

usually because

• –The local database (Docker, Postgres.app) isn't running
• –A paused free-tier database (Supabase and Neon pause or suspend idle projects)
• –The direct host is IPv6-only and your network or host has no IPv6: use the provider's pooler host
• –Wrong host or port, or a firewall / IP allow list blocking the server

fix

1. 1.Start or unpause the database, then retry
2. 2.Copy a fresh connection string from the provider dashboard (for Supabase from a serverless host, use the pooler connection string)
3. 3.Check the host's IP allow list if your provider has one

P1000: Authentication failed against database server

Authentication failed against database server, the provided database credentials for `postgres` are not valid.

Please make sure to provide valid database credentials for the database server at the configured address.

The server was reached but rejected the username or password in DATABASE_URL.

usually because

• –A password with @, #, / or : that isn't URL-encoded, so the URL is parsed wrong
• –The database password was reset and the env var still has the old one
• –Pooler connection strings that need the user as postgres.<project-ref>, not just postgres

fix

1. 1.URL-encode special characters in the password (@ becomes %40, # becomes %23)
2. 2.Copy the full connection string again from the provider and update it everywhere
3. 3.Redeploy after changing environment variables

P2021: The table does not exist in the current database

PrismaClientKnownRequestError:
Invalid `db.invoice.findMany()` invocation:

The table `public.Invoice` does not exist in the current database.

The client knows about the model, but the database it's connected to was never given that table. The schema changed and nobody pushed or migrated this database.

usually because

• –The agent added a model and ran prisma generate, but not db push or migrate
• –Production points at a different database than the one you migrated locally
• –Migrations exist but the deploy never runs prisma migrate deploy

fix

1. 1.Local prototype: npx prisma db push
2. 2.With migrations: npx prisma migrate dev locally, then npx prisma migrate deploy against production
3. 3.Check DATABASE_URL points at the database you think it does

P2002: Unique constraint failed

PrismaClientKnownRequestError:
Invalid `db.user.create()` invocation:

Unique constraint failed on the fields: (`email`)

You tried to create or update a row with a value that must be unique (an email, a Stripe customer id, a slug) and another row already has it.

usually because

• –Sign-up or seed code that always calls create, even when the record exists
• –A Stripe webhook delivered twice, each delivery creating the same row
• –Two requests racing to create the same record

fix

1. 1.Use upsert when "create or update" is what you mean
2. 2.Catch the error by code: error instanceof Prisma.PrismaClientKnownRequestError && error.code === "P2002", and show a friendly message
3. 3.For webhooks, store the event id with a unique constraint and skip duplicates

await db.user.upsert({
  where: { email },
  update: { stripeCustomerId },
  create: { email, stripeCustomerId },
});

P2025: Record required but not found

PrismaClientKnownRequestError:
Invalid `db.user.update()` invocation:

An operation failed because it depends on one or more records that were required but not found. No record was found for an update.

update, delete, connect or a findUniqueOrThrow / findFirstOrThrow call needed a row that wasn't there.

usually because

• –Updating by an id or email that doesn't exist (or belongs to another user's filter)
• –Deleting something that was already deleted, often a double-clicked button or a retried webhook
• –connect: { id } pointing at a missing related record

fix

1. 1.If missing is normal, use updateMany / deleteMany (they return a count instead of throwing) or findUnique and check for null
2. 2.Otherwise catch code P2025 and return a 404
3. 3.Check the where clause uses a field that's really unique for this user

P2003: Foreign key constraint violated

PrismaClientKnownRequestError:
Invalid `db.post.create()` invocation:

Foreign key constraint violated on the foreign key

A row points at a related row that doesn't exist (on create or update), or you deleted a row that other rows still point at.

usually because

• –Creating a record with a userId from a stale session or a hard-coded id
• –Deleting a user that still has posts, subscriptions or accounts
• –Seed scripts that insert children before parents

fix

1. 1.Use connect with an id you just read from the database (or the signed-in session)
2. 2.Add onDelete: Cascade to the relation if children should go with the parent, then push or migrate
3. 3.Insert parents before children in seeds, or wrap both in db.$transaction

PrismaClientValidationError: Unknown argument

PrismaClientValidationError:
Invalid `db.user.findMany()` invocation:

{
  where: {
    emial: "[email protected]",
    ~~~~~
  }
}

Unknown argument `emial`. Did you mean `email`? Available options are marked with ?.

The query uses a field or option the generated client doesn't know. Prisma checks every query against your schema before sending it.

usually because

• –The agent guessed a field name (userId vs ownerId, createdAt vs created_at)
• –The field exists in schema.prisma but the client wasn't regenerated
• –A relation filter written like a scalar: where: { user: id } instead of where: { userId: id }

fix

1. 1.Use the name Prisma suggests after "Did you mean"
2. 2.If the field is new, run npx prisma generate
3. 3.Let TypeScript check queries: don't type db or the query args as any

PrismaClientValidationError: Argument is missing

PrismaClientValidationError:
Invalid `db.post.create()` invocation:

{
  data: {
    title: "Hello",
+   user: {
+     create: UserCreateWithoutPostsInput | UserUncheckedCreateWithoutPostsInput,
+     connectOrCreate: UserCreateOrConnectWithoutPostsInput,
+     connect: UserWhereUniqueInput
+   }
  }
}

Argument `user` is missing.

A required field or relation wasn't provided. The lines marked with + show what Prisma expected.

usually because

• –Creating a child record without its owner (no userId and no user: { connect })
• –A new required field added to the schema, while existing create calls weren't updated

fix

1. 1.Pass the relation: user: { connect: { id: session.user.id } } (or userId directly)
2. 2.When adding a required field to an existing model, give it a @default or make it optional first

P2024: Timed out fetching a new connection from the connection pool

PrismaClientKnownRequestError: Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 10, connection limit: 5)

Every connection Prisma may open is busy, or the database refused more. In Next.js this is almost always too many PrismaClient instances, or serverless functions each holding their own pool.

usually because

• –new PrismaClient() in many files, or inside a request handler
• –next dev hot reload creating a fresh client on every change (no globalThis singleton)
• –Serverless functions connecting straight to Postgres instead of through a pooler

fix

1. 1.Create PrismaClient once in lib/db.ts with the globalThis pattern and import db everywhere
2. 2.On serverless, use the provider's pooled connection string (Supabase port 6543 with ?pgbouncer=true, or Neon's -pooler host)
3. 3.Use a direct (non-pooled) URL as directUrl in schema.prisma, for migrations

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL") // pooled
  directUrl = env("DIRECT_URL")   // direct, used by migrate
}

Drift detected: database schema is not in sync with migration history

Drift detected: Your database schema is not in sync with your migration history.

We need to reset the "public" schema at "localhost:5432"

You may use prisma migrate reset to drop the development database.
All data will be lost.

prisma migrate dev compared the database to the migrations folder and they disagree: something changed the database outside a migration.

usually because

• –The agent ran prisma db push on a database that also uses migrate
• –Someone edited a table by hand in the provider's dashboard
• –A migration file was edited or deleted after it was applied

fix

1. 1.On a dev database with throwaway data, let migrate reset it
2. 2.Never answer yes on a database with real data: back it up, then create a migration for the difference (prisma migrate diff) or baseline
3. 3.Pick one workflow per database: db push for prototypes, migrate for anything in production

P3005: The database schema is not empty

Error: P3005

The database schema is not empty. Read more about how to baseline an existing production database: https://pris.ly/d/migrate-baseline

prisma migrate deploy found tables but no migration history, usually because the database was created with db push. It won't guess which migrations are already applied.

usually because

• –The project started with prisma db push and later switched to migrations
• –Tables created by hand or by another tool

fix

1. 1.Create a baseline migration from the current schema
2. 2.Mark it as applied with npx prisma migrate resolve --applied <migration_name>
3. 3.Run npx prisma migrate deploy for later migrations

P3009: migrate found failed migrations

Error: P3009

migrate found failed migrations in the target database, new migrations will not be applied. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve
The `20261025_add_invoices` migration started at 2026-10-25 14:02:11 UTC failed with the following logs: …

A previous migrate deploy failed halfway, and Prisma blocks every later migration until you say what happened to that one.

usually because

• –A migration that adds a required column to a table that already has rows
• –A unique index on a column with duplicate values
• –A timeout or lost connection during deploy

fix

1. 1.Read the failed migration's error and fix the data or the SQL
2. 2.If the changes were rolled back: npx prisma migrate resolve --rolled-back <name>, then deploy again
3. 3.If you applied them by hand: npx prisma migrate resolve --applied <name>

Prisma Client could not locate the Query Engine

PrismaClientInitializationError: Prisma Client could not locate the Query Engine for runtime "rhel-openssl-3.0.x".

This happened because Prisma Client was generated for "darwin-arm64", but the actual deployment required "rhel-openssl-3.0.x".

The client was generated on one OS (your Mac, Windows or a different Linux) and deployed to another, so the native engine file for the server isn't there.

usually because

• –The generated client or node_modules was committed or copied from your laptop
• –A Docker image on Alpine (linux-musl) while the client was generated on Debian
• –A monorepo or custom output path the bundler doesn't copy

fix

1. 1.Run prisma generate during the build on the target machine, not locally
2. 2.Don't commit node_modules or the generated client
3. 3.If you must generate elsewhere, add the target to binaryTargets in the generator block

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "rhel-openssl-3.0.x"]
}