Prisma 8 Upgrade: What Breaks and How to Migrate

Prisma 8 replaces schema.prisma, prisma generate and PrismaClient with a contract and a new query API. Pin prisma@7 now, then upgrade step by step.

On 14 November 2026 the latest tag of the prisma package on npm points to 8.0.0-rc.33, a release candidate. Anyone who runs npm install prisma@latest, or starts a new project from an old tutorial, gets a CLI that has no generate, no migrate dev and no db push. I run Prisma 7 with PostgreSQL in production for clients and on this website's API, so I tested what actually breaks. I built a Prisma 7.10.1 app, upgraded it to Prisma 8 on PostgreSQL 18.7 and Node 24.22.3, and quote the real output below.

Key takeaways

• Prisma 8 is still a release candidate, but it is the npm latest tag. Prisma 7 gets bug and security fixes for 18 months after Prisma 8 reaches general availability.
• Existing projects don't jump by themselves. A "prisma": "^7.10.1" range stayed on 7.10.1 in my test. Only prisma@latest or a fresh install pulled in 8.
• The old commands are gone: prisma generate fails with CLI.UNKNOWN_COMMAND, and migrate dev tells you to use contract emit, migration plan and db migrate.
• Your schema.prisma still works as input. prisma7Schema() reads it, and prisma db sign adopts the existing database without touching data.
• Every query must be rewritten. prisma.board.findMany() becomes db.orm.public.Board...all(), so plan it like a real migration.

Is Prisma 8 released?

Not as a final release. Prisma's release status page calls Prisma ORM 8 a release candidate "you can install and build with today" and says the changelog will announce the final release. On 14 November the current versions are [email protected] (published 6 November) and @prisma/[email protected].

The same page sets the support windows that matter for planning:

• Prisma 7: bug fixes and security updates for 18 months from the day Prisma 8 reaches general availability.
• Prisma 6: security patches only, until 19 November 2026. If you are still on 6, that date is next week.

So there is no rush to rewrite a working Prisma 7 app. The urgent job is to make sure nothing installs Prisma 8 by accident.

What happens when npm installs Prisma 8 by accident?

First the good news. In my Prisma 7 project, npm install -D prisma without a version kept the existing range and stayed on 7.10.1, because npm's caret range doesn't match pre-release versions. Then I ran what many people do when a tutorial tells them to update:

$ npm i -D prisma@latest
$ grep '"prisma"' package.json
    "prisma": "^8.0.0-rc.33",
$ npx prisma generate
✘ [CLI.UNKNOWN_COMMAND] No command registered for `generate`
→ List every command: prisma --help
$ npx prisma migrate dev
✘ [CLI.COMMAND_MOVED] `migrate dev` has been replaced
  why: Prisma 8 emits the contract, plans the migration and applies it in separate steps ...
→ Use the replacement: prisma contract emit
$ npx prisma db push
✘ [CLI.UNKNOWN_COMMAND] No command registered for `push`, did you mean `update`?

Any build or postinstall script that calls prisma generate now fails, so your CI and Docker builds go red. The fix is one line:

npm install --save-dev --save-exact prisma@7
npm install --save-exact @prisma/client@7

Pin both packages with an exact version and commit the lockfile. Do the same in Dockerfiles and CI steps that run npx prisma without a local install, because npx prisma outside a project downloads the latest tag. If your build already failed after an upgrade, also check my fix for the Prisma 7 datasource url error, which is the other common break from the 6 to 7 move.

What changed in Prisma 8?

Prisma 8 is a new design, not a version bump. The Coming from Prisma ORM 7 page lists the changes. The ones that affect most apps:

• Schema becomes contract. The data model lives in contract.prisma. Prisma now uses "schema" to mean a PostgreSQL schema such as public, which is why queries read db.orm.public.Board.
• Generate becomes emit. prisma contract emit writes contract.json and contract.d.ts. There is no generated PrismaClient class; you create the client yourself in a small db.ts.
• Migrations are planned, then applied. migrate dev is split into migration plan and db migrate, and the database carries a signature (marker) of the contract it matches.
• Removed: the generator and datasource blocks, implicit many-to-many relations, connectOrCreate and nested update/set writes, list filters like has and hasSome, $extends, and the studio command.
• PostgreSQL first. The driver package is @prisma/orm-postgres and the upgrade guides cover PostgreSQL. If you use MySQL, SQLite or MongoDB, stay on Prisma 7 until Prisma documents your database.

How do I upgrade from Prisma 7 to Prisma 8?

I followed Prisma's PostgreSQL upgrade guide with npm instead of bun. Requirements: Node 22.18+, 24.11+ or 26+, and TypeScript 5.9+ with strict. Do this on a branch with a fresh database backup (my pg_dump guide shows a backup that actually restores).

1. Install Prisma 8 with exact versions

npm i -D -E [email protected]
npm i -E @prisma/[email protected] dotenv

Remove prisma generate from your build and postinstall scripts.

2. Point the new config at your old schema

// prisma.config.ts
import "dotenv/config";
import { definePrismaConfig } from "prisma/config";
import { defineConfig, prisma7Schema } from "@prisma/orm-postgres/config";

export default definePrismaConfig({
  orm: defineConfig({
    contract: prisma7Schema("prisma/schema.prisma"),
    output: "src/prisma",
    db: { connection: process.env["DATABASE_URL"] },
  }),
});

3. Emit the contract and sign the existing database

$ npx prisma contract emit
✔ Emitted contract.json and contract.d.ts
$ npx prisma db sign
✔ app: signed 0529967683...4c4168 (no marker before)
✔ Database signed

db sign introspected my tables and wrote a marker. It didn't change any table or row.

4. Hand migrations to Prisma 8

$ npx prisma migration plan --name init
✔ Planned baseline (5 operation(s)) + 0 operation(s)
migrations/app/20261114T0935_baseline
├─ Create table "Board"
├─ Create table "Post"
...
$ npx prisma db migrate
✔ Already up to date
$ npx prisma db verify
✔ Database marker and schema match contract

The baseline describes the tables that already exist, and db migrate applied no operations to my live data. After that, the old prisma/migrations folder can be retired. Future changes follow contract emit, then migration plan --name <change>, then db migrate --advance-ref db.

The animated diagram of this upgrade is in the original post.

5. Create the client and rewrite queries

// src/db.ts
import "dotenv/config";
import postgres from "@prisma/orm-postgres/runtime";
import { contractFromJson } from "@prisma/orm-postgres/static";
import type { Contract } from "./prisma/contract.d";
import contractJson from "./prisma/contract.json";

export const db = postgres({
  contract: contractFromJson<Contract>(contractJson),
  url: process.env["DATABASE_URL"]!,
});

Then each query changes shape. Before and after for a list with a relation count:

// Prisma 7
const boards = await prisma.board.findMany({
  include: { _count: { select: { posts: true } } },
  orderBy: { createdAt: "asc" },
});

// Prisma 8
const boards = await db.orm.public.Board
  .include("posts", (posts) => posts.count())
  .orderBy((b) => b.createdAt.asc())
  .all();

My test script printed [{"createdAt":"2026-11-14T09:37:01.847Z","id":1,"slug":"news-...","posts":1}]. Notice that the count sits directly on posts, so every _count.posts in your views must change. Unique lookups are now .where({ slug }).first(), and creates take a plain object: db.orm.public.Post.create({ boardId, title }).

Two things tripped me up. My script used top-level await, which tsx refused in a CommonJS project, so I renamed it to .mts and imported the JSON with with { type: "json" }. And Prisma's guide warns that DateTime fields can come back as strings; in my run with these versions they were Date objects, so test your own date handling instead of trusting either.

6. Remove the old client

npm remove @prisma/client @prisma/adapter-pg
rm -rf node_modules/.prisma src/generated
npm run build && npx prisma db verify

Should you upgrade to Prisma 8 now?

For a production app, my advice is no, not while it is a release candidate. Pin Prisma 7, keep shipping, and plan the rewrite for after general availability. The 18-month support window is plenty of time.

Two cases where starting now makes sense: a brand new PostgreSQL project with no Prisma 7 code to port, or a large app where you want to try Prisma's route-by-route guide, which runs Prisma 7 and 8 side by side so you can move one endpoint at a time. If you're comparing ORMs anyway because of this rewrite, my Prisma vs Drizzle comparison covers the trade-offs.

Frequently asked questions

Why does prisma generate say unknown command?

Your project is running the Prisma 8 CLI, which replaced prisma generate with prisma contract emit. If you didn't mean to upgrade, install prisma@7 and @prisma/client@7 with exact versions and rebuild.

Does Prisma 8 still use schema.prisma?

Not directly. New projects write a contract.prisma file, but during an upgrade the prisma7Schema() helper reads your existing schema.prisma and emits the contract from it, so you don't have to rewrite the model on day one.

Will upgrading to Prisma 8 delete my data?

Not in my test. prisma db sign only wrote a marker, and the baseline migration applied zero operations to the existing tables. Prisma 8 migrations also ask before they drop data. Back up first anyway.

How long is Prisma 7 supported?

Prisma says Prisma 7 keeps receiving bug fixes and security updates for 18 months from the day Prisma 8 reaches general availability. That date isn't announced yet, so the window hasn't started.

Does Prisma 8 support MySQL and SQLite?

The current upgrade guides and the @prisma/orm-postgres package cover PostgreSQL. If your app runs on MySQL, SQLite or MongoDB, stay on Prisma 7 until Prisma documents your database for version 8.

Need help with a Prisma upgrade?

I build and maintain Next.js and NestJS apps on Prisma and PostgreSQL, and I can pin, upgrade or port your data layer without downtime. See my web development services or tell me about your project.

Originally published on rakibulinux.com, where I write tested fixes for Linux, DevOps and full-stack apps.