Prisma 7 Migration Playbook: Typed SQL, Rust Deprecation

Prisma 7 is the most consequential ORM release of 2026 — a migration that changes the query engine, the generator output path, the supported runtimes, and how raw SQL is typed. Underneath the bumps, the story is a single thesis: Prisma is no longer a Node-shaped library with a Rust sidecar; it is a pure-TypeScript and WASM ORM that runs anywhere JavaScript runs.

What's at stake: every existing Prisma 6 deployment has a decision to make in the next two quarters. Stay on 6 and accept a slowly receding security-fix horizon, or migrate to 7 and pick up faster cold starts, first-class Edge support, and typed raw SQL in exchange for one week of focused engineering. For most teams this is the easiest large dependency bump of the year — provided the rollout is sequenced correctly.

This guide covers seven stages: what actually shipped in v7, the Rust deprecation story, the typed-SQL surface, the generator path footgun, the runtime selection matrix, a phased rollout plan, and the four pitfalls that bite in real migrations. Every step is grounded in patterns we've run on production codebases, not release-note paraphrasing.

Prisma 7 is unusual among ORM releases because every breaking change pulls in the same direction: drop the Rust binary, become a pure-TypeScript and WASM library, expose typed primitives where Prisma used to expose untyped escape hatches. Each of the four axes below is significant in isolation; together they reframe what Prisma actually is.

The first axis is the query engine. Prisma 6 shipped a per-platform Rust binary that handled query planning and execution. Prisma 7 deprecates that binary and replaces it with a pure-TypeScript driver layer plus a WASM-compiled query planner, talking directly to your database via driver adapters (@prisma/adapter-pg, @prisma/adapter-neon, and friends). The second axis is typed SQL — a new surface that types both parameters and result rows for raw queries, removing the longstanding $queryRawUnsafe escape hatch as a necessary tool. The third is the generator path — output now lives at @/generated/prisma/client, a naming change that breaks every existing import in the codebase. The fourth is runtime selection — Edge runtimes (Cloudflare Workers, Vercel Edge, Next.js Edge Functions) are now first-class targets, not experimental adapters.

None of these are surprises if you have followed the Prisma roadmap — each axis has been telegraphed in successive 6.x minor releases via preview-feature flags. The v7 release is mostly the moment those preview features become defaults and the deprecation paths flip to errors. For teams who've been running on 6.x with the preview flags enabled, the migration is largely a flag flip and an import sweep. For teams on stock 6.x without preview features, it's closer to a week of focused work.

The Rust query engine was the single largest source of deployment friction in Prisma 6. Shipping a per-platform binary meant every build had to pick the right binaryTargets for the deployment environment, cold-start latency carried the cost of loading the binary, and container images carried the cost of bundling it. Edge runtimes never supported the Rust engine at all; Edge support shipped via driver adapters that bypassed it.

Prisma 7 makes the driver-adapter path the only path. The query planner — what used to live in the Rust binary — is compiled to WASM and shipped as a regular npm dependency. The wire protocol and connection handling live in pure-TypeScript driver adapters (@prisma/adapter-pg for node-postgres, @prisma/adapter-neonfor Neon's HTTP and WebSocket drivers, @prisma/adapter-planetscale for PlanetScale, and so on). Your Prisma Client constructor now takes an explicit adapter:

// lib/db.ts — Prisma 7 client construction
import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from '@/generated/prisma/client';

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

The migration step is a one-line addition to the client constructor plus the adapter dependency in package.json. The connection string moves out of the Prisma schema datasource (where it lived as an environment reference) and into the adapter constructor. The schema file's datasource db block still exists for generator purposes — provider, relation mode, preview features — but the actual connection now flows through the adapter.

For teams currently shipping Prisma to Vercel Serverless Functions, the practical effect is meaningfully faster cold starts on routes that hit the database. For teams shipping to Edge runtimes, the practical effect is that Edge becomes tractable for ORM-backed routes for the first time without preview flags. Both wins are large enough to justify the migration on their own.

Typed SQL is the feature that quietly changes how teams should think about raw queries in Prisma. The longstanding pattern was: use the typed query builder for 90% of access patterns, drop down to $queryRaw or $queryRawUnsafe for the 10% the builder couldn't express, accept that the return type was unknown and validate manually. The v7 surface kills the type-safety gap entirely.

How it works

Raw SQL files live in a sql/ directory next to your Prisma schema. Each file is compiled to a TypeScript function by prisma generate; both parameters and the result row shape are fully typed against the database schema. Calls flow through the $queryRawTyped client method.

-- prisma/sql/getActiveUsersByPlan.sql
SELECT
  u.id, u.email, u.created_at, COUNT(o.id)::int AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.plan = $1
  AND u.active = true
GROUP BY u.id
ORDER BY order_count DESC
LIMIT $2;

// usage — both params and rows are typed
import { getActiveUsersByPlan } from '@/generated/prisma/sql';
import { prisma } from '@/lib/db';

const rows = await prisma.$queryRawTyped(
  getActiveUsersByPlan('pro', 25),
);
// rows: { id: string; email: string; created_at: Date; order_count: number }[]

Why this matters

Three workload classes graduate from "risky escape hatch" to "first-class tool". Reporting aggregates with window functions and grouping that the query builder can't express cleanly. Recursive CTEs for hierarchical data — comment threads, organizational graphs, materialized paths. Performance-critical paths where the SQL planner picks a better plan when given the raw query than when reconstructing it from the builder's output.

The migration pattern that holds up: triage your existing $queryRaw and $queryRawUnsafe call sites first. Anything performance-critical or anything that handles user input should move to typed SQL files in the same migration. The discipline payoff is real — once typed SQL is available, reviewers should reject new $queryRawUnsafe calls in code review unless there's a measured reason the typed surface won't work.

The generator output path moved one directory level deeper. In Prisma 6, configuring output = "../generated/prisma" in your schema and importing from @/generated/prisma resolved cleanly. In Prisma 7, the same output config produces a directory whose public entry point is @/generated/prisma/client — the bare path is no longer the import target.

This is the migration's most common source of confusion. The error TypeScript surfaces is innocuous-looking — a missing module or a missing named export — but it shows up in a thousand places at once because every import in the repo is wrong.

The sweep itself is straightforward — but order matters. Do the import sweep before running the schema-level adjustments (adapter wiring, typed-SQL preview flag) because the adapter examples in the v7 docs all assume the new path. Trying to wire the adapter while the import path is still wrong produces confusing errors that look like adapter problems but are really import-path problems.

The sweep pattern

# 1. Update the schema generator block
generator client {
  provider = "prisma-client"   // note: was "prisma-client-js" in v6
  output   = "../generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters", "typedSql"]
}

# 2. Sweep the codebase
rg -l 'from "@/generated/prisma"' --type ts \
  | xargs sed -i '' 's|from "@/generated/prisma"|from "@/generated/prisma/client"|g'

# 3. Regenerate and build
npx prisma generate
npm run typecheck
npm run build

Two small notes. First, the generator provider also renamed from prisma-client-js to prisma-client — leaving the old provider in the schema produces a silent no-op rather than a hard error in some setups. Second, if you previously had the generated client at the default location (node_modules/.prisma/client), the explicit output field is now required — the v7 generator refuses to write to node_modules by default.

Prisma 7's runtime story is the cleanest the ORM has ever shipped, but it requires a deliberate choice per deployment target. The driver adapter is the variable; the rest of the stack — query planner, generated client, schema — is identical across runtimes. Pick the adapter that matches your database and your runtime, then the deployment is straightforward.

The decision rule is simple in practice: pick the adapter that matches your database's preferred driver in your target runtime. Don't mix Edge runtimes with TCP-based adapters (the Edge runtime doesn't support persistent sockets); don't use HTTP adapters in long-running Node when a pooled TCP connection would be cheaper.

For new Next.js 16 apps deploying to Vercel, adapter-pgon the Node runtime is the boring default that works. Reach for Edge adapters when a specific route's latency profile justifies it — typically reads that fan out across regions. Our web development engagements usually default to Node + adapter-pg and route a small number of latency-critical paths to Edge.

The migration sequence that holds up across teams is five phases, run in order, each gated by a measurable outcome. The order matters — running phase 3 before phase 1 produces a morass of unrelated errors. The whole sequence is typically a week for a small-to-medium app and two to three weeks for a large monorepo, dominated by phase 4 testing rather than phase 2 code changes.

Two operational notes. The migration is genuinely reversible during phases 1-4 — keep the branch alive and the v6 deployment untouched until phase 5 wraps. After phase 5 ships, the schema file's preview-feature flags and the adapter wiring make a clean revert harder than a typical dependency rollback; you'd need to revert the schema and regenerate as well. Plan for it but don't rely on it.

For teams running Prisma in multiple repos (microservices, monorepo apps), do not parallelize across repos until one repo has cleared phase 5. The patterns that emerge from the first migration — the import-sweep regex, the adapter wiring file, the typed-SQL conversion criteria — apply directly to the second and third. Sequential rollouts compound learning; parallel rollouts compound mistakes.

The v7 migration has four predictable failure modes. Each is recoverable, but all four are easier to avoid than diagnose. We've seen each of them on production migrations; the pattern is consistent enough to be worth documenting.

1. Import-path drift

The find-and-replace sweep usually catches 90% of imports, but test files, scripts, and seed files live outside the main app tree and get missed. Run the sweep against **/*.{ts,tsx,js,mjs} globs, not just app/**. Test files often import generated types directly for fixture typing — those imports break too.

2. Connection pool silent saturation

The v7 runtime swap shifted the default pool sizing heuristic. For most apps the new defaults are fine; for apps that operate at the edge of their pool budget, the new defaults can land under-sized. The failure mode is subtle: requests queue, p95 climbs by 50-150ms, error rates stay flat. Audit your connection_limitquery parameter on the database URL or your adapter's explicit pool configuration after the bump.

3. Edge adapter mismatched to database

Picking @prisma/adapter-neonwith a non-Neon Postgres works in development (HTTP queries succeed) but fails in production under load because Neon's HTTP driver assumes Neon's wire protocol. Match adapter to database, not adapter to runtime — runtime is a secondary filter on the adapter choice, not the primary one.

4. Skipping typed-SQL on the migration

The migration succeeds without touching $queryRaw call sites. But every $queryRawUnsafeleft in place is risk debt the new schema makes harder to repay later — once typed SQL is the house default, mixed-style code in the same repo signals to reviewers that "raw queries are fine here". The window during the migration is the cheapest moment to convert. Prioritize the highest-risk call sites: anything that handles user input, anything performance-critical, anything with complex result shapes the team has gotten wrong before.

Beyond the four predictable pitfalls, expect surprises in shape rather than substance. Anything that depends on the specific shape of generated types — runtime type validation, ORM wrappers, ORM-aware testing helpers — will likely need a small touch-up. The cleanest way to surface those is a clean npx tsc --noEmit run after phase 3; anything red in that pass is something you have to touch before phase 4 testing is meaningful.

For teams that built domain logic on top of Prisma — repository patterns, service objects, query builders that wrap $queryRaw — the v7 migration is also a natural moment to flatten that wrapper layer. Typed SQL replaces most of the reasons those wrappers existed; the call sites that were wrapping for type-safety can now call the typed surface directly. The wrapper layer often shrinks by 30-50% during a properly scoped v7 migration. If you have a sync agent in the stack — our Zoho-to-Supabase sync tutorial walks through the database side of a similar pattern — the same audit applies there.