Prisma 6 to 7: The Rust Engine Is Gone, What Changed?

If you're on Prisma 6 and npm install prisma surprised you by pulling in the 8.x series, you're not alone: the latest tag on npm now points to Prisma 8's release candidate (8.0.0-rc.13), even though the recommended stable version for production is still 7.10.0. This post is a safe migration guide from Prisma 6 to Prisma 7 — the version that removed the Rust engine entirely, introduced prisma.config.ts, and made driver adapters mandatory — plus why Prisma 8 is still an RC and when to actually move to it.

💡 Pro Tip: Before you start the migration, run npm view prisma dist-tags — the latest tag may point to an RC release, so for production you should explicitly write [email protected].

Table of Contents

• Prisma 7 Architecture: Rust Engine Replaced by WASM
• Why it matters
• What the Query Compiler does, why driver adapters are still needed
• Removed components
• Moving to prisma.config.ts
• schema.prisma isn't replaced, its role changes
• Minimum version requirements
• Pitfalls in Projects With a Custom Output Path
• Watch out for CI/CD caching
• The import path gets one level deeper
• Check tsconfig and bundler path aliases too
• Driver Adapters GA — What Changed for Postgres
• Think about the connection pool at the adapter level
• Running Migrations Safely (migrate diff, without --force)
• Don't forget the seed script
• Bundle Size and Cold Start Measurement
• Why this number matters on serverless
• A simple measurement script
• What's in the Prisma 8 RC, When to Migrate
• Version confusion when reading the docs
• A compatibility package for a gradual migration
• Rollback Plan
• Rehearse on staging, don't get surprised in production
• FAQ
• What breaking changes are there when moving from Prisma 6 to 7?
• What is prisma.config.ts — does it replace schema.prisma?
• How is a custom client output path defined in Prisma 7?
• Should I use the Prisma 8 RC in production?
• Conclusion
• Sources

Prisma 7 Architecture: Rust Engine Replaced by WASM

For years, Prisma's query engine was written in Rust and shipped as a native binary (Query Engine) — separate builds were needed for runtimes like LibraryEngine, BinaryEngine, DataProxyEngine, AccelerateEngine, and ReactNativeEngine. With Prisma 7, that's history: the engine is now a "Query Compiler" written in TypeScript and WebAssembly, with no native binary download step. The rollout was gradual — per the official Rust-to-TypeScript blog post, the new architecture went production-ready in v6.16, then became the default with Prisma 7.0.0 (November 19, 2025).

Why it matters

Removing native binaries directly affects cold start time in serverless/edge environments (Vercel Edge, Cloudflare Workers) — no more binary download or native-module loading at cold start. The first two bullets of the official 7.0.0 announcement are literally: "90% smaller bundle output" and "3x faster query execution".

What the Query Compiler does, why driver adapters are still needed

In the old architecture, the Rust binary both translated the query into SQL and ran it against the database — one closed box. Now those jobs are split: the TypeScript/WASM Query Compiler only translates the Prisma query into SQL, while a driver adapter (such as @prisma/adapter-pg) handles the actual connection and execution. That's why, as you'll see next, you now have to pass an adapter to PrismaClient — without one there's nothing to run the SQL the compiler produces.

Removed components

This table is based on the architectural change notes in Prisma's official 7.0.0 changelog (November 19, 2025). In practice, you no longer look for a separate native binary after prisma generate, but you now have to define a driver adapter for every database — more on that next.

Moving to prisma.config.ts

In Prisma 7, schema.prisma still holds your model definitions — it doesn't go away. What changes is the connection info the CLI needs for migrations/introspection: the official upgrade guide marks url, directUrl, and shadowDatabaseUrl in the datasource block as deprecated, and the CLI stops with P1012 if it sees them in the schema file. The connection now lives in prisma.config.ts, which has no separate directUrl field — write that value into url instead; the only accepted fields are url and shadowDatabaseUrl.

1import "dotenv/config";
2import { defineConfig, env } from "prisma/config";
3 
4export default defineConfig({
5  schema: "prisma/schema.prisma",
6  migrations: {
7    path: "prisma/migrations",
8    seed: "tsx prisma/seed.ts",
9  },
10  datasource: {
11    url: env("DATABASE_URL"),
12  },
13});

Leave this line in schema.prisma and the CLI stops you with P1012: "The datasource property 'url' is no longer supported in schema files" — the exact message from a real GitHub issue.

schema.prisma isn't replaced, its role changes

prisma.config.ts is a configuration file — your model/table definitions still live in schema.prisma. The difference: previously the CLI auto-read .env and resolved the url in datasource; now that resolution logic is written explicitly inside prisma.config.ts (the dotenv/config import and the type-safe env() helper above are for exactly this). It's more transparent which env var migration/seed commands read, but forget it and prisma migrate fails to find a connection.

Prisma's official reference page defines schema, migrations.path, migrations.seed, and datasource.url inside prisma.config.ts — the seed script now lives here instead of the prisma.seed field in package.json.

Minimum version requirements

These values come from the official upgrade guide; Prisma 6 was more relaxed here, so projects on an older Node LTS may need a runtime upgrade too. The ESM requirement can mean extra conversion work for old CommonJS seed scripts (ones using require()).

Pitfalls in Projects With a Custom Output Path

For projects using a custom output path like src/generated/prisma, this is Prisma 7's most painful change. In Prisma 6, output in the generator client block was optional — omit it and the client generated into node_modules/@prisma/client. Prisma 7 reverses this: output is now required, and generating into node_modules by default is gone entirely.

1generator client {
2  provider = "prisma-client"
3  output   = "../src/generated/prisma"
4}

Note: provider also changed — the new Rust-free client needs prisma-client instead of the old prisma-client-js. Miss this one line and generate keeps producing the old JS client, with none of the new architecture's performance gains.

Watch out for CI/CD caching

Change the generator client block without re-running prisma generate, and the new provider/output settings never take effect — the compiler keeps seeing the old files. If a CI/CD pipeline has a cache-restore step for node_modules or the build cache (.next/cache, .turbo) that skips prisma generate, that can look like "I made the change but nothing happened" in production. Checking the build logs on the first few post-migration deploys — confirming prisma generate actually ran and wasn't skipped from cache — is the most practical way to catch this early.

The import path gets one level deeper

In projects using a custom output, the import line also changes — the generated client is now written into a client subfolder:

1// Prisma 6 (old)
2import { PrismaClient } from "../generated/prisma";
3 
4// Prisma 7 (new)
5import { PrismaClient } from "../generated/prisma/client";

This line is easy to miss because the compile error isn't clear — a "Cannot find module" message can send a developer who forgot the output change in the wrong direction (path alias, tsconfig). Checking every import by hand is safer than trusting IDE autocomplete, since the old path may still exist on disk (a stale build) and silently resolve.

Check tsconfig and bundler path aliases too

Projects with a custom output usually also define a tsconfig path alias (like @/generated/prisma). If it still points to the old folder depth, the IDE may show no error because its server keeps using a stale cache — but an actual tsc --noEmit or production build blows up. Running a type check from the command line, without restarting the IDE first, prevents a false-green migration.

1npx tsc --noEmit

With a framework like Next.js, also confirm the standalone build output copies the new client path — update any hard-coded reference to the old path in build scripts (a cp -r command, for example).

Driver Adapters GA — What Changed for Postgres

In Prisma 7, the new way of creating a Prisma Client requires a driver adapter for every database. For projects using PostgreSQL, this adapter is @prisma/adapter-pg (based on node-postgres):

1import { PrismaClient } from "../generated/prisma/client";
2import { PrismaPg } from "@prisma/adapter-pg";
3 
4const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
5const prisma = new PrismaClient({ adapter });

The practical effect on a PostgreSQL + Prisma setup: PrismaClient can no longer be called without arguments — you must pass an adapter object. If new PrismaClient() calls are scattered across the project (API routes, cron scripts, the seed file), re-exporting from one central client module saves you from writing the adapter setup repeatedly.

⚠️ Note: Prisma 7 doesn't yet support MongoDB — the official migration guide says MongoDB users should stay on Prisma 6 for now.

Think about the connection pool at the adapter level

Once you move to a driver adapter, connection pooling becomes the underlying driver's responsibility (node-postgres) — pooling logic that used to live inside the Rust engine now depends on the pg.Pool settings wrapped by @prisma/adapter-pg. With many concurrent function invocations in a serverless environment, manually tuning pool size (max) against the database's connection limit is worth revisiting to avoid "too many connections" errors post-migration.

Running Migrations Safely (migrate diff, without --force)

Independent of the version migration, there's a permanently valid discipline when applying migrations to production: never apply a schema change without making it visible first. The prisma migrate diff command shows the difference between two schema/database states as SQL without changing anything — using it as a gate in CI lets you catch an unexpected DROP COLUMN before it ever reaches production:

1npx prisma migrate diff \
2  --from-config-datasource \
3  --to-schema=prisma/schema.prisma \
4  --script

Flags like prisma db push --force-reset or migrate reset --force belong only on local/staging, where losing data is acceptable — always moving forward in production with prisma migrate deploy, after reading the migrate diff output, is the one rule that doesn't change with Prisma 7 either.

Don't forget the seed script

When you move to prisma.config.ts, the seed command's definition moves too — from the prisma.seed field in package.json to migrations.seed. Leaving both in place at once causes confusion; remove the old prisma field from package.json entirely and keep prisma.config.ts as the single source of truth. The real breaking change: in Prisma 6, prisma migrate dev/migrate reset used to run the seed script automatically after a migration; that's removed in Prisma 7 — you now run npx prisma db seed explicitly. That's why running seed manually on staging during rehearsal and checking the expected data can't be skipped.

Bundle Size and Cold Start Measurement

Prisma's official 7.0.0 announcement spells out the Rust-free architecture's results point by point: 90% smaller bundle output, 3x faster query execution, noticeably lower CPU/memory usage. These are Prisma's own numbers — the most practical way to verify them yourself is logging the same serverless function's cold start time before and after the migration.

Why this number matters on serverless

Removing the native binary directly affects the function package's disk footprint and how long it takes to read at cold start — in the old architecture, every cold start had to find and load the right platform-specific binary (Linux/musl/ARM, say). The WASM-based engine skips this step. Trust an actual measurement in your environment over a guess — the official number is an upper bound, and your real gain depends on the platform.

A simple measurement script

You don't need complex tooling for the exact number on your own project — a few lines importing the client and measuring connection time are enough:

1const start = performance.now();
2import { PrismaPg } from "@prisma/adapter-pg";
3const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
4const { PrismaClient } = await import("../generated/prisma/client");
5const prisma = new PrismaClient({ adapter });
6await prisma.$connect();
7console.log(`init: ${(performance.now() - start).toFixed(1)}ms`);

Run this script with the old client before the migration and the new one after, in the same environment (same serverless region, same database), then compare the two numbers — the most practical way to see your project's real gain instead of trusting the official figures.

What's in the Prisma 8 RC, When to Migrate

As of 2026-09-08, the dist-tags of the prisma package on npm read: prev: 7.10.0, latest: 8.0.0-rc.13, next: 8.0.0-rc.10. So npm install prisma today installs a release candidate directly — not what you want in production.

1# Wrong: blindly installs latest (could be RC)
2npm install prisma
3 
4# Right: explicitly pin the version for production
5npm install [email protected] @prisma/[email protected]

Prisma's docs site now shows Prisma 8 content by default, while Prisma 7's docs live at a separate /orm/v7 path — so Prisma 8 has been announced, but there's still no stable 8.0.0 on npm. For a low-risk production migration, it's safer to finish the 6-to-7 move first, pin the version at 7.10.0, and plan the jump to 8 as a separate step once a stable release ships.

Version confusion when reading the docs

This default-to-8 doc setup is a real trap when you land on a doc page from a search engine: the example code you're looking at might belong to Prisma 8, while you're still on Prisma 7. Checking whether /v7 is in the URL whenever you open any Prisma doc page keeps you from copying a not-yet-stable 8.x API into production code.

A compatibility package for a gradual migration

On the same day as 7.10.0 (August 25, 2026), the Prisma team published @prisma/prisma7 on npm — its description literally reads "Compatibility wrapper for running the Prisma 7 CLI", and it installs a prisma7 command, so you can still call 7's commands under a separate name after moving to 8.x. A practical bridge for those who'd rather go "6 to 7, then 7 to 8" as two separate, controlled steps; more on that in a separate post once 8 hits GA.

Rollback Plan

If something goes wrong during the migration, the rollback consists of clear, reversible steps:

• Pin the version in package.json: downgrade the prisma and @prisma/client packages to the last 6.x release before 7.x (npm install prisma@6 @prisma/client@6).
• Restore the generator client block: provider = "prisma-client-js", remove the output field (or revert it to its old path).
• Remove prisma.config.ts, put url back in the datasource block: in Prisma 6 the connection info is defined again inside schema.prisma.
• Remove the driver adapter: revert new PrismaClient({ adapter }) to a parameterless new PrismaClient(), remove the @prisma/adapter-pg dependency.
• Flatten the import paths by one level: .../generated/prisma/client → .../generated/prisma.

Since each step is the exact reverse of one taken during the migration, keeping every change in its own commit makes rolling back much faster — especially when a production issue needs fixing within 5 minutes.

Rehearse on staging, don't get surprised in production

The most valuable part of a rollback plan is never using it. Running the whole migration end-to-end on staging first — generator change, prisma.config.ts, driver adapter, import paths — through a real deploy cycle surfaces most production surprises ahead of time. Moving to production only after both tsc --noEmit and prisma migrate diff come back green in CI turns the rollback plan into "a safety net that's possible but shouldn't be needed."

FAQ

What breaking changes are there when moving from Prisma 6 to 7?

The biggest change: the whole family of Rust-based query engines (LibraryEngine, BinaryEngine, DataProxyEngine, AccelerateEngine, ReactNativeEngine) is removed entirely, replaced by a TypeScript/WASM Query Compiler. As a result, a driver adapter is now required for every database (@prisma/adapter-pg for PostgreSQL), the generator block's provider changes from prisma-client-js to prisma-client, output becomes mandatory, and datasource connection info moves into prisma.config.ts. Prisma 7 also ships as ESM (type: module required), and SSL defaults change — invalid certificates are no longer ignored, so you may see a P1010 error.

What is prisma.config.ts — does it replace schema.prisma?

No, it doesn't. schema.prisma still holds the model definitions; prisma.config.ts holds the connection URL and migration path that the CLI uses for migration, introspection, and seed operations. In Prisma 7, the url line in the datasource block has to be removed from the schema file, otherwise the CLI throws a P1012 error.

How is a custom client output path defined in Prisma 7?

The output field in the generator client block is now mandatory: specify a path like output = "../src/generated/prisma", and set provider to prisma-client. Importing from the generated client is one level deeper now — .../generated/prisma/client, not the old .../generated/prisma.

Should I use the Prisma 8 RC in production?

No. As of 2026-09-08, 8.0.0-rc.13 is still at the release candidate stage; even though the latest tag on npm points to this version, you need to explicitly pin the version to 7.10.0 for production installs. For those who want a gradual migration, the @prisma/prisma7 compatibility package the Prisma team shipped alongside 7.10.0 provides a bridge.

Conclusion

The Prisma 6-to-7 migration isn't a refactor that changes everything at once — it's a controlled process: update the generator block, create prisma.config.ts, add the driver adapter, fix the import paths, in that order. In projects with a custom output path, the most commonly missed step is that output becomes mandatory and the import path gets deeper; a checklist (the Reader Reward above) makes rollback easier too. Since Prisma 8 is still RC, finishing this migration also sets you up for the next leap.

For more on ORM and database choices, see the Drizzle ORM with Turso/SQLite edge pattern. On serverless frameworks, there's production serverless architecture with Hono.js, and for edge functions, Supabase Edge Functions and the Deno runtime. If GraphQL plus managed Postgres interests you, Firebase Data Connect with GraphQL/Cloud SQL is worth a read, and on vector databases, the Pinecone, Weaviate, and Qdrant comparison rounds things out.

Sources

• Prisma ORM 7.0.0 Announcement — the Rust-free architecture, and the claims of 90% smaller bundle and 3x faster query execution
• Prisma Changelog: 2025-11-19 — the official release date of Prisma ORM 7.0.0 and the architectural change notes
• From Rust to TypeScript: A New Chapter for Prisma ORM — the WASM-based Query Compiler architecture becoming production-ready starting with v6.16
• Prisma 7 Upgrade Guide — the output field, import path, minimum Node/TypeScript versions, and the MongoDB exception
• prisma.config.ts Reference — the defineConfig structure, the schema and migrations fields
• npm prisma dist-tags — live proof that the latest tag points to an 8.0.0-rc release
• GitHub Issue #28573 — a real production example of the datasource url error
• npm: @prisma/prisma7 — the 7.10.0 release date and the official package description