Prisma 7: Rust-free client, smaller bundles, edge-ready dep…

Prisma 7 is the outcome of the long Rust → TypeScript client migration the team telegraphed in the v6 era. The headline isn't a single feature; it's the absence of one — the Rust query engine is gone from the default client, replaced by a TypeScript implementation that runs natively in every JavaScript runtime your code already supports.

"We remember hearing about Prisma's move away from Rust and thinking about how not dealing with the native addon API would make supporting Prisma in Deno so much simpler. We were all really excited to see it!" — Luca Casonato, Deno

The team publishes headline metrics that match what teams reported during the v6 preview: ~90% smaller bundle output, ~3× faster query execution, lower CPU/memory, and fewer headaches on Vercel Edge and Cloudflare Workers.

"I upgraded a few weeks ago and it was great to see how well everything went and how easy it was to switch to the new Rust-Free Client." — Kent C. Dodds

TL;DR

No Rust binary in the default client. The query engine is now TypeScript end-to-end.
~90% smaller bundle, ~3× faster query execution, lower memory footprint.
Edge-ready by construction — Vercel Edge, Cloudflare Workers, Deno, Bun all "just work" without polyfills or special builds.
New generator — switch provider from "prisma-client-js" to "prisma-client".
`prisma.config.ts` consolidates configuration.
Generated client lives in source by default, not in node_modules.
Faster types thanks to collaboration with the ArkType author on smaller type surfaces.
Prisma Postgres is positioned as a managed-database product with standard Postgres wire compatibility.

Why removing Rust matters

The Rust engine was originally the right choice. In 2018–2020, building a high-performance ORM that worked in Node and other runtimes was easier with a native binary that could be loaded as an N-API addon. The cost showed up over time:

Bundle size. The binary added megabytes per platform target.
Edge runtimes. Cloudflare Workers, Vercel Edge, and Deno's serverless variants either banned native addons outright or required you to opt in to special build modes (prisma generate --no-engine, accelerator proxies, custom Docker images).
Cold start. Loading and initializing the engine added latency on serverless functions.
Debugging surface. A bug at the engine boundary required understanding two languages and the FFI in between.

Prisma 7 retires that bridge. The query engine is TypeScript; bundlers see one language; edge runtimes see ordinary JS.

The new client generator

The provider name changes:

// schema.prisma
generator client {
  provider = "prisma-client"   // was: "prisma-client-js"
  output   = "../src/generated/prisma"
}

A few things to notice:

`prisma-client` (no -js) is the new TypeScript-native generator. prisma-client-js still exists but is now legacy.
`output` points into your source tree by default, not into node_modules. This fixes a long list of paper cuts: IDE indexing, file watchers, monorepo path resolution, and "why did my client get clobbered after npm install?".
The output is ESM. CJS compatibility paths exist where needed, but new projects should expect to be ESM.

`prisma.config.ts`

Configuration scattered across schema.prisma, .env, and package.json scripts now consolidates:

// prisma.config.ts
import { defineConfig } from "prisma/config";

export default defineConfig({
  schema: "./prisma/schema.prisma",
  migrations: { directory: "./prisma/migrations" },
  seed: { command: "tsx prisma/seed.ts" },
});

The benefits are mostly editorial: there's one place to look, the file is typed (you cannot misspell a key without a compile error), and the config is portable across CI environments. Existing projects keep working without a config file; you opt in when you want it.

Performance, in detail

The numbers from the announcement bear inspection:

~3× faster query execution. Most of the win comes from removing the IPC hop to the Rust engine. A cold query that previously crossed the boundary twice (request and response) now stays in JS the whole time.
~90% smaller bundle. No platform-specific binary to ship. Serverless function packages drop from tens of megabytes to small JS bundles.
Lower CPU and memory. The Rust engine had its own thread pool and memory model; consolidating into the JS event loop is more efficient for the overwhelming majority of workloads.

These wins are most visible on edge and serverless deploys. A long-running Node server saw smaller percentage gains in the v6 previews because the engine cost amortized; on a Cloudflare Worker, the win is more dramatic because the engine cost dominated each cold start.

Edge runtimes

Prisma 6 already supported Edge through Accelerate (a managed proxy). Prisma 7 makes the direct path the default:

Vercel Edge. Standard @prisma/client works without an Accelerate connection.
Cloudflare Workers. Direct support; uses Hyperdrive when configured.
Deno. No native addon dance; Deno's permission model is honored.
Bun. Direct support; the all-JS engine is happy in Bun's runtime.

The Accelerate proxy is still relevant if you want managed connection pooling or global query caching, but it's a feature you opt in to, not a workaround for the engine boundary.

Faster types

Large Prisma schemas had a real type-check cost — IDEs would lag, tsc --watch would slow down. The Prisma team collaborated with the ArkType author on type representations that fold faster:

Generated types are smaller and use fewer conditional branches.
Inference for relational queries scales better with schema size.
Editor responsiveness on schemas with hundreds of models improves.

The impact is hard to quantify in a release note but is the kind of thing teams notice on day one — auto-complete simply feels snappier.

`Prisma Postgres`

Alongside the ORM, the team introduced Prisma Postgres as a managed-database product:

Standard wire compatibility. Tools that speak the Postgres wire protocol — TablePlus, DataGrip, psql, Hyperdrive, other ORMs — can connect directly.
Quick start with npm create db.
Tight integration with Accelerate caching and pooling for teams that want them.

Treat it as an option, not a requirement. Prisma 7's ORM works against any Postgres (and MySQL, SQLite, MongoDB, SQL Server).

Migration: this is a major

A few things that will catch you on the upgrade:

Generator name change. Update schema.prisma and run prisma generate.
Output path moves. If your client was somewhere unusual, double-check the new output location and update imports.
CJS-only consumers. ESM-by-default may force a tooling adjustment. Most modern bundlers handle it; legacy build chains may need configuration.
Engine-specific options — anything you set via engineConfig, prisma generate --no-engine, or platform-specific binary targets is no longer relevant.
Edge workarounds can be removed. If you maintained a separate @prisma/client/edge import or special bundler config, it's no longer needed.

The official migration guide walks through these step by step. Allow a half-day for a typical app, longer for monorepos with many services.

When to wait

A few cases where pinning to 6.x is reasonable:

You depend on a Prisma extension that hasn't shipped a 7.x build.
Your CI pipeline assumes the legacy engine binary path (e.g., explicit engines/ cache).
You ship a UI library that consumes Prisma types and need a peer-version range that includes both 6 and 7.

For everything else, Prisma 7 is the kind of release that justifies upgrading even mid-quarter — the edge-runtime story alone changes what's possible.

Operational details to watch

A few things that won't be obvious from the announcement but matter when you actually run Prisma 7 in production:

Connection pooling. The TypeScript client doesn't change connection semantics, but the cold-start improvement means more functions can fit in their cold-start budget without a connection pooler. Whether you still need pgBouncer or Hyperdrive depends on your workload, not on Prisma.
Query caching. Accelerate's query caching layer is unchanged; the new client integrates with it the same way the v6 client did.
Logging. Prisma 7's query logger emits structured events; if you've been parsing console logs to extract query timings, switch to the event API for cleaner integration with OpenTelemetry, Datadog, or your tracing backend of choice.
Prepared statements. The TypeScript engine still uses prepared statements where appropriate, but the cache shape changed slightly. If you monitor pg_prepared_statements on your database, expect different statement names.
Telemetry opt-out. Prisma's CLI sends usage telemetry by default. If your security policy requires opt-out, the PRISMA_TELEMETRY_DISABLED=1 environment variable still works in 7.x.

None of these are blockers; they're just the operational details that surface a week into running the new client.

Schema and migration tooling

Prisma 7 doesn't change prisma migrate or prisma db push semantics, but it tightens a few behaviors:

`prisma generate` is faster because it skips the Rust binary fetch.
`prisma migrate dev` detects schema drift more reliably; the previous detector occasionally missed changes in views or generated columns.
`prisma studio` is faster on large databases, particularly when browsing tables with many indexes.
`prisma db pull` introspection of existing databases is more accurate for Postgres-specific types (intervals, ranges, tsranges).

If you've been working around any of these limitations, run a fresh prisma db pull on a copy of your production schema and check the diff.

Where this connects

If your stack also touches PostgreSQL 18, the PG 18 release post covers async I/O and other server-side wins; combined with Prisma 7 on the client, the read path gets meaningful improvements at both layers. Drizzle teams tracking similar work will recognize the pattern from the Drizzle 1.0 RC — both ecosystems are pushing performance through better mapping/codec layers.

References

Source / further reading: Prisma blog

Prisma 7: Rust-free client, smaller bundles, edge-ready deployments