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

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), 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 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)

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.

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

Rewrite the PrismaClient generation to the adapter-mandatory form.

// 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).

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.

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

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.

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

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

// 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).

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

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.