# Prisma v6 → v7 migration guide: safely crossing Rust-free, mandatory driver adapters, the prisma-client generator, prisma.config.ts, and the removal of middleware

> An implementation guide to safely migrating Prisma ORM from v6 to v7. With procedures and a checklist per breaking change, it covers: the removal of the Rust engine and mandatory driver adapters, the generator becoming prisma-client (output required, escaping node_modules, import-source change), migrating config to prisma.config.ts, the removal of $use middleware → Client Extensions, Prisma.validator becoming legacy → satisfies, the removal of auto-seeding, and removed CLI flags.

- Published: 2026-06-26
- Author: 友田 陽大
- Tags: Prisma, TypeScript, PostgreSQL, アーキテクチャ設計, 型安全
- URL: https://tomodahinata.com/en/blog/prisma-orm-v6-to-v7-migration-guide
- Category: Prisma ORM
- Pillar guide: https://tomodahinata.com/en/blog/prisma-orm-production-guide-type-safe-database-v7-driver-adapters

## Key points

- The core of v7 is the removal of the Rust engine. The query engine becomes TS + WASM, and a driver adapter (for PostgreSQL, @prisma/adapter-pg) is mandatory for all DBs. The official benchmark shows up to 3.4× faster and about 90% smaller bundle.
- The generator becomes prisma-client. output is required and it's no longer generated in node_modules, with imports fully changed from @prisma/client to the generated path.
- Config moves to prisma.config.ts. Declare with defineConfig + env. Environment variables aren't auto-loaded, so use dotenv alongside it.
- $use middleware is removed → Client Extensions ($extends). Prisma.validator becomes legacy → TypeScript's satisfies.
- Auto-seeding is removed (only explicit db seed), and some CLI flags are removed. The safe approach is staged migration: first fix it to a working form (generator, adapter, import), then optimize.

---

Prisma ORM **v7** (released November 2025) isn't a mere version bump but **a generational change of architecture.** The long-bundled **Rust query engine is removed**, and the way the client is generated, how it connects, and where the config lives have all changed. The benefits are large — the official benchmark shows **up to 3.4× faster and about 90% smaller bundle (about 14MB → 1.6MB)**, and deployment to edge/serverless is dramatically simplified. On the other hand, **v6 code won't run as-is.**

This article is an implementation guide for **safely migrating Prisma from v6 to v7.** It crushes the breaking changes one at a time, with procedures. For a fresh implementation premised on v7, see the [Prisma ORM production-operations guide (v7)](/blog/prisma-orm-production-guide-type-safe-database-v7-driver-adapters), and for post-migration data modeling, migrations, and performance, the spoke articles.

> **Rules for this article**: procedures and breaking changes are based on **Prisma's official v7 upgrade guide/changelog (as of June 2026).** Always verify the migration in staging before applying it to production, and confirm the latest procedures in each [official](https://www.prisma.io/docs/guides/upgrade-prisma-orm/v7) document. The subject is PostgreSQL.

---

## 0. Mental model: first make it work, then polish

A large dependency overhaul becomes a swamp if you try to rewrite everything to "the ideal form" all at once. What I observed in the payment-platform dependency overhaul was the order "**first get it to a working form with the minimum change, then optimize incrementally.**"

The v7 migration is the same. **The first things to fix are just 3** — the generator, the driver adapter, and the import paths. With this, Prisma starts working. Going to Client Extensions, building out `prisma.config.ts`, and replacing with `satisfies` can proceed in order once it works. Separating "works" from "clean" is the trick to completing a migration.

> **The shortest path to migration**: ① the generator to `prisma-client` + an `output` specification → ② generate `PrismaClient` with a driver adapter → ③ the import source to the generated path. It boots up to here. The rest is follow-up.

---

## 1. What changed (the big picture of breaking changes)

| Area | v6 (old) | v7 (current) |
| --- | --- | --- |
| Query engine | Bundles a Rust binary | **Rust-free** (a TS + WASM query compiler) |
| generator | `prisma-client-js` (generates in `node_modules`) | **`prisma-client`** (`output` required, in-code generation) |
| driver adapter | Optional (Preview) | **Mandatory for all DBs** (PostgreSQL is `@prisma/adapter-pg`) |
| import source | `@prisma/client` | **The generated path** (e.g., `../generated/prisma/client`) |
| Config | The `"prisma"` key in `package.json` | **`prisma.config.ts`** (`defineConfig`) |
| Middleware | `$use` | **Removed** → Client Extensions (`$extends`) |
| Validation helper | `Prisma.validator` | **Legacy** → `satisfies` |
| Seed | Auto-run on `migrate dev`, etc. | **Only explicit `db seed`** (auto removed) |
| Some CLI flags | `--skip-generate`, etc. | Some **removed** |

Below, I explain in the order you'll do the hands-on work in migration.

---

## 2. Introducing the driver adapter and rebuilding PrismaClient

Since the Rust engine is gone, **explicitly bring in the driver adapter that handles the connection.** This is the heart of the v7 migration.

```bash
npm install @prisma/client@7 @prisma/adapter-pg
npm install -D prisma@7
```

Rewrite the `PrismaClient` generation to the adapter-mandatory form.

```ts
// v6（旧）
// import { PrismaClient } from "@prisma/client";
// export const prisma = new PrismaClient();

// v7（新）
import { PrismaPg } from "@prisma/adapter-pg";
import { PrismaClient } from "./generated/prisma/client"; // ← 生成先からimport

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
export const prisma = new PrismaClient({ adapter });
```

The official docs state the v7 change plainly: "**the new way to create a Prisma Client has changed to require a driver adapter for all DBs.**" Note that connection-pool tuning has also moved from the connection string's query parameters to **the adapter-side options** (→ [performance-optimization guide §5](/blog/prisma-performance-optimization-n-plus-1-connection-pool-guide)).

---

## 3. The generator to `prisma-client` (output required)

Rewrite the schema's generator block. **`output` becomes required**, and the generated artifact appears **inside your repository**, not in `node_modules`.

```prisma
// v6（旧）
// generator client {
//   provider = "prisma-client-js"
// }

// v7（新）
generator client {
  provider     = "prisma-client"          // 新generator
  output       = "../src/generated/prisma" // 生成先（必須）
  runtime      = "nodejs"                  // 必要なら edge/bun などへ
  moduleFormat = "esm"                     // esm | cjs
}
```

The practical work this entails.

- **Fully replace the import source**: `@prisma/client` → the generated path (e.g., `@/generated/prisma/client`). `PrismaClient`, the `Prisma` namespace, and error types — all of them. You can fix it mechanically with the editor's bulk replace.
- **`.gitignore` the generated artifact**: ignore `src/generated/`, and always run `prisma generate` before the CI/deploy build (`postinstall`, etc.). Block "shipped to production without generating" with the build procedure.

```bash
npx prisma generate # 新generatorでクライアントを再生成
```

---

## 4. Config to `prisma.config.ts`

Move the config you put in the `"prisma"` key of `package.json` in v6 (seed, etc.) to the type-safe **`prisma.config.ts`.**

```ts
// prisma.config.ts（プロジェクト直下）
import "dotenv/config"; // v7は環境変数を自動読込しない
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
    seed: "tsx prisma/seed.ts",
  },
  datasource: {
    url: env("DATABASE_URL"),
  },
});
```

**Sticking point**: v7 **doesn't auto-load** environment variables. Explicitly load them with `import "dotenv/config"`, etc. Config becoming code raises reproducibility in monorepos and CI.

---

## 5. Middleware `$use` → Client Extensions

**`$use` middleware is removed in v7.** The official wording is "**the client-middleware API is removed. Use Client Extensions where possible.**" Port logging and instrumentation to the `query` extension of `$extends`.

```ts
// v6（旧）：$use ミドルウェア
// prisma.$use(async (params, next) => {
//   const start = Date.now();
//   const result = await next(params);
//   console.log(`${params.model}.${params.action} ${Date.now() - start}ms`);
//   return result;
// });

// v7（新）：Client Extensions
export const prisma = basePrisma.$extends({
  query: {
    $allModels: {
      async $allOperations({ model, operation, args, query }) {
        const start = performance.now();
        const result = await query(args);
        console.log(JSON.stringify({ model, operation, ms: Math.round(performance.now() - start) }));
        return result;
      },
    },
  },
});
```

Extensions **return a new client per extension**, so you can limit the scope of application and the types are preserved. It's a safer design than middleware.

---

## 6. `Prisma.validator` → `satisfies`

`Prisma.validator<...>()` becomes **legacy (only for the old `prisma-client-js`)** and can't be used with the new generator. Replace it with TypeScript-native **`satisfies`** + the generated types.

```ts
// v6（旧）
// const userSelect = Prisma.validator<Prisma.UserSelect>()({ id: true, email: true });

// v7（新）：satisfies で同等の型チェック
import { Prisma } from "./generated/prisma/client";

const userArgs = { include: { posts: true } } satisfies Prisma.UserDefaultArgs;
type UserWithPosts = Prisma.UserGetPayload<typeof userArgs>;
```

`satisfies` "conforms the literal's shape to the generated type while preserving inference," so it fulfills `validator`'s role more straightforwardly (→ [Prisma production-operations guide §4](/blog/prisma-orm-production-guide-type-safe-database-v7-driver-adapters)).

---

## 7. Changes to seed and CLI flags

### 7.1 Removal of auto-seeding

In v7, "**seeding starts only on the explicit `npx prisma db seed`. Auto-seeding on `migrate dev` / `migrate reset` is removed.**" Fix scripts premised on "reset and it enters automatically" in CI or locally to explicit execution. The seed itself also requires a driver adapter (→ [Migrate production-operations guide §8](/blog/prisma-migrate-production-zero-downtime-cicd-guide)).

### 7.2 Removed CLI flags

`--skip-generate` / `--skip-seed` and some DB URL flags, etc., were removed. Check whether these remain in CI scripts or documentation, and lean toward a `prisma.config.ts`-based configuration.

> **Other points to note**: peripheral features you used, such as the removal of the Metrics preview feature, may be affected. Cross-check the features you use in your project against the list in the official v7 upgrade guide.

---

## 8. How to proceed with the migration (recommended flow)

Staged migration, in a safe order.

1. **Cut a branch and verify in staging** (don't apply directly to production).
2. **Update dependencies** (`prisma`, `@prisma/client` to v7, add `@prisma/adapter-pg`).
3. **The generator to `prisma-client` + `output`**, `prisma generate`.
4. **Make `PrismaClient` adapter-equipped**, **bulk-replace imports to the generated path.** → here it **first works.**
5. Crush type errors (move the import source of the `Prisma` namespace and error types to the generated path too).
6. **`$use` to Extensions**, **`validator` to `satisfies`.**
7. **Move config to `prisma.config.ts`**, and seed to explicit `db seed` execution.
8. **Update CI**: `prisma generate` before the build, production application is `migrate deploy`, remove removed flags.
9. Confirm major flows with regression tests/E2E, and go staging → production.

> **Observability and rollback**: split migration PRs small and pass tests at each stage. Just in case, prepare dependency-version pinning and a rollback procedure. An app's dependency overhaul, like the payment platform's zero-downtime migration, isn't scary if you observe "staged, verified, rollback-able."

---

## 9. v6 → v7 migration checklist

- [ ] `prisma` / `@prisma/client` to v7, add a driver adapter (`@prisma/adapter-pg`)
- [ ] The generator to `prisma-client`, **specify `output`**, run `prisma generate`
- [ ] Rewrite to `new PrismaClient({ adapter })` (adapter mandatory)
- [ ] **Bulk-replace the import source to the generated path** (`PrismaClient`, `Prisma`, error types)
- [ ] `.gitignore` the generated artifact, force `prisma generate` before the CI/deploy build
- [ ] Port `$use` middleware to **Client Extensions (`$extends`)**
- [ ] Replace `Prisma.validator` with **`satisfies` + `GetPayload`**
- [ ] Move config to **`prisma.config.ts`** (`defineConfig` + `env`). Explicitly load env vars with `dotenv`
- [ ] Seed to **explicit `db seed` execution** (remove the auto-seed premise)
- [ ] Remove the **CLI flags** (`--skip-generate`, etc.) that were removed, from scripts
- [ ] Migrate connection-pool settings to the adapter side
- [ ] Regression tests/E2E in staging → go to production incrementally. Prepare a rollback procedure

---

## Conclusion

The migration to Prisma v7, despite the many headings, has at its **core just two things: "mandatory driver adapters" and "the generator becoming `prisma-client`."** First make it work with these two (+ import replacement), then put Extensions, `prisma.config.ts`, and `satisfies` in order — with staged migration that separates "works" from "clean," you can complete it safely. What you gain is the real benefit of speed, lightness, and ease of edge deployment from going Rust-free.

"I want to safely complete the migration to Prisma v7 without stopping production," "I want to advance a large dependency overhaul without accidents via staged migration and regression tests" — from designing the migration plan through PR splitting, CI updates, and verification, I help leveraging the knowledge of zero-downtime overhaul on a payment platform.