prisma correction pack · for projects on prisma@7 / @prisma/client@7

What we actually measured

6 Claude models were asked for idiomatic prisma code with no tools, purely from training knowledge. 51 reproduced failures across 32 runs, each verified against the release that broke the belief.

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest prisma release whose contents the model can correctly attribute to that release — not the newest prisma feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs early — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest prisma is 7.10.0 (verified 2026-09-12). Separately from the corrections below, 3 of 32 runs recorded a version fact — the model named a current prisma version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

How to read an entry

Every entry ends with a Reproduced against line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

Two dates, and this file needs only one. The entries below were last checked against their primary sources on 2026-09-12. None of the 39 has had its own text change since that sweep.

The corrections

Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

prisma migrate diff --from-schema-datamodel

Renamed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

prisma migrate diff renamed its inputs. --from/to-schema-datamodel became --from/to-schema; --from/to-url and --from/to-schema-datasource became --from/to-config-datasource, which reads the datasource out of prisma.config.ts. Diffing two different URLs is no longer possible, because only one config applies at a time.

The stale belief: That you diff a schema file against a live database with --from-schema-datamodel ./prisma/schema.prisma --to-url $DATABASE_URL.

# Stale
npx prisma migrate diff \
  --from-schema-datamodel prisma/schema.prisma \
  --to-url "$DATABASE_URL" \
  --script

# Current
npx prisma migrate diff \
  --from-schema prisma/schema.prisma \
  --to-config-datasource \
  --script

Reproduced against: Claude Fable 5 (S1), Claude Opus 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removal of prisma migrate flags · 2025-11-19

engineType

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The client engines are gone: LibraryEngine (engineType = "library"), BinaryEngine (engineType = "binary"), DataProxyEngine and ReactNativeEngine, and with them the PRISMA_CLIENT_ENGINE_TYPE, PRISMA_QUERY_ENGINE_BINARY, PRISMA_QUERY_ENGINE_LIBRARY and PRISMA_CLI_QUERY_ENGINE_TYPE environment variables. Prisma 7's query compiler is a WebAssembly module inside the client.

The stale belief: That query execution goes through a Rust engine binary you select with engineType and can tune with PRISMA_* environment variables.

// Stale
generator client {
  provider   = "prisma-client-js"
  engineType = "binary"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

generator.runtime = "react-native" was removed in the same release. MEASURED 2026-09-12 (BACKLOG 1h-n-iv, JOURNAL/164): the ENGINES are gone, and the schema KEY that named them is not — engineType is accepted by prisma generate on every release from 6.0.0 to 7.10.0, and from 7.0.0 every value emits the same files as omitting it. So the stale_code above does not fail on Prisma 7; it generates silently, and the only thing that changes is that the CLI stops printing , engine=binary in its success line. That is prisma LF39, which carries the boundary and the controls.

Reproduced against: Claude Fable 5 (S2), Claude Sonnet 5 (S2) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removed Client Engines · 2025-11-19

import { PrismaClient } from '@prisma/client'

Behaviour changed in prisma 7.0.0 (2025-11-19)

Import the client from your generated output path, not from @prisma/client. This follows from output being required by the prisma-client generator (LF4): the generated client is a file in your repository, and there is nothing at @prisma/client to import from.

The stale belief: That @prisma/client is the import path — true from Prisma 2 through 6.

// Stale
import { PrismaClient } from '@prisma/client'

// Current
import { PrismaClient } from './generated/prisma/client'

The exact specifier depends on where you set output and where the importing file lives. AUDIT 2026-09-02 (JOURNAL/038): it also depends on your module resolution. Under moduleResolution: node16 or nodenext — the setting an ESM project takes, and LF19 requires "type": "module" — the extensionless form is TS2835 and the import must be written './generated/prisma/client.js'. Under bundler (Next.js, Vite) the extensionless form is correct. Both were compiled on 7.0.0 and 7.10.0. PRECISION FIX 2026-09-08: this row's second sentence said "output being required" flatly, and LF4's rewrite the same day narrowed that to the prisma-client generator — a project that stays on prisma-client-js with no output still generates into node_modules/@prisma/client at 7.10.0 and still imports from @prisma/client. The advice above is for the generator Prisma 7 documents, which is the one this pack prescribes.

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Upgrade to Prisma ORM 7 — Schema changes

new PrismaClient()

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 31 releases, prisma 6.0.0 through 7.10.0

Constructing the client with no arguments is no longer supported. Prisma 7 requires either a driver adapter or an accelerateUrl. new PrismaClient() and new PrismaClient({}) were both removed in 7.0.0. Whether you see that before you run it depends on which generator wrote your client: against the client prisma-client emits — the generator Prisma 7 documents, and the one the corrected code below imports from — both constructions are COMPILE errors from 7.0.0 (TS2554 for the no-argument case, TS2345 for {}); against the legacy prisma-client-js client both still type-check at 7.10.0 and the only failure is a runtime throw at construction. The message has been rewritten twice: 7.1.0 added one dedicated to the no-argument case, and 7.9.0 replaced both (PrismaClient was instantiated without any options. A driver adapter is required to connect to your database. and PrismaClient requires a driver adapter to connect to your database, but none was provided.), so an agent matching on prisma's older error text will not find it.

The stale belief: That the client reads the datasource out of schema.prisma and needs nothing at construction — true for the whole of Prisma 1 through 6.

// Stale
import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

// Current
import { PrismaClient } from './generated/prisma/client'
import { PrismaPg } from '@prisma/adapter-pg'

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

Measured on 31 rungs, 6.0.0-7.10.0 (JOURNAL/156, extended JOURNAL/158). The adapter package depends on the database: @prisma/adapter-pg for Postgres, @prisma/adapter-better-sqlite3 for SQLite, @prisma/adapter-mariadb for MySQL/MariaDB. new PrismaClient() constructs on every 6.x release and throws on every 7.x one. THE TYPE-LEVEL CLAUSE IS GENERATOR-DEPENDENT and was published as if it were not: this Index compiled the two constructions against the client prisma-client-js emits and found them legal on all thirty-one rungs, which is true and is not the declaration a Prisma 7 reader writes against. Against the prisma-client client the same two constructions are type errors on all eleven 7.x rungs and on none below — TS2554 "Expected 1 arguments, but got 0" and TS2345 for {} — a contiguous boundary at 7.0.0, the fact's own release. (Below 6.8.0 that generator answers nothing: it does not exist below 6.6.0, and the 6.6.0/6.7.0 clients import node: builtins this program carries no typings for. The boundary sits twelve rungs above the lowest rung that can see.) The declaration this Index read before, @prisma/client/runtime/client.d.ts, is the runtime bundle's internal constructor, one layer below anything a reader imports. The third clause is exact: 7.0.0 throws a bare Cannot read properties of undefined (reading '__internal') for the no-argument case, 7.1.0 replaces it with a message naming that case, and 7.9.0 rewrites both again — executed, and the 7.9.0 note's own claim that both "include a copy-pasteable example and a link to the driver adapters docs" holds: the example prisma prints is this entry's corrected code, PrismaPg and an import from ./generated/prisma/client.

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Prisma Client changes · 2025-11-19 · Upgrade to Prisma ORM 7 — Driver adapters · Prisma 7.9.0 release notes — fixes and improvements · 2026-07-20

package.json prisma key

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The prisma key in package.json is no longer read. Schema path and seed command move to prisma.config.ts (schema and migrations.seed).

The stale belief: That the seed script and a custom schema path are declared in a prisma block in package.json — the documented location since 2.18.

// Stale
{
  "prisma": {
    "schema": "./custom-path/schema.prisma",
    "seed": "tsx ./prisma/seed.ts"
  }
}

// Current
// Current — the key is not read. Declare these in prisma.config.ts instead:
//   export default defineConfig({
//     schema: 'prisma/schema.prisma',
//     migrations: { seed: 'tsx prisma/seed.ts' },
//   })

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removed support for prisma keyword in package.json · 2025-11-19

prisma generate --no-engine

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

prisma generate no longer accepts --no-engine, --data-proxy, --accelerate or --allow-no-models. The first three existed to strip or swap the Rust query engine, which Prisma 7 does not ship at all.

The stale belief: That prisma generate --no-engine is the way to shrink a serverless bundle — the standard Accelerate/edge deployment advice for v5 and v6.

# Stale
npx prisma generate --no-engine

# Current
npx prisma generate

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removal of prisma generate flags · 2025-11-19

prisma.config.ts

New requirement in prisma 7.0.0 (2025-11-19) · boundary measured on 31 releases, prisma 6.0.0 through 7.10.0

prisma.config.ts is required for any project that runs introspection or migrations. The datasource URL lives there, not in schema.prisma — and that half is true from 7.0.0 and not before: every 6.x release still requires the schema's own url, though from 6.18.0 a url in the config overrides it where both are present, provided the engine key that release requires sits beside it. The file itself is older than Prisma 7: the CLI loads it from 6.5.0 and honours its schema path from 6.6.0, and it became mandatory in 7.0.0. A config exported as a plain object rather than through defineConfig needed earlyAccess: true until 6.13.0, and from 6.13.0 is refused if it still carries that key.

The stale belief: That project configuration is split between schema.prisma and a prisma key in package.json, with no config file in the picture.

import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'

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

Corrected 2026-09-11 (JOURNAL/153). This row said the file "was introduced as opt-in in 6.18.0". Executed on all 31 stable minors from 6.0.0 to 7.10.0: 6.4.0 looks for the file but ships no prisma/config to write it with; 6.5.0 (2025-03-11) loads a defineConfig file and then crashes on its schema key; from 6.6.0 (2025-04-08) the schema path is honoured. A plain exported object is loaded only with earlyAccess: true on 6.6.0-6.12.x and only without it from 6.13.0 (2025-07-29), the release whose note moves the file to General Availability; below 6.6.0 it is refused either way. 6.18.0 is where the datasource URL and an engine key were added to the file (its release note; see LF9), not where the file began. The 6.18.0 note also says prisma init now creates the file; that cannot be dated from an install, because from 6.8.0 to 6.19.0 prisma init downloads @prisma/cli-init@latest from npm and runs that, so it scaffolds whatever that package is on the day it runs. SECOND SENTENCE DATED 2026-09-12 (JOURNAL/170), and it was this fact's last undated clause. Executed on all 31 stable minors from 6.0.0 to 7.10.0 with prisma db pull against a url named ONLY in prisma.config.ts (a loopback literal with nothing listening, so the CLI's own P1001 names the host it dialled and no packet leaves the machine): the config's url stands in for the schema's from 7.0.0 and on no 6.x rung, where the schema is refused for Argument "url" is missing in data source block. The 6.18.0 release note does NOT move that date, measured with the engine key that release requires beside the datasource: the control arm reads identically to the plain one on all 31 rungs. What 6.18.0 added is narrower and is dated here as a window — with a url in BOTH places, [6.18.0, 7.0.0) dials the CONFIG's, and below 6.18.0, or at 6.18.0/6.19.0 with engine dropped, the config's datasource is discarded SILENTLY and the schema's url is dialled. The rows are LF7g (the clause), LF7h (its control arm) and LF7i (the window, stated as that conjunction); all three confirmed on the committed bisector. Why this clause waited: the rows that existed (LF7c-LF7f) read Loaded Prisma config from and The schema at app.prisma is valid, and through defineConfig a file loads carrying keys the plain-object loader refuses — so neither says a key IN it was used, and a loaded datasource is not a dialled url.

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Schema and config file updates · 2025-11-19 · Prisma 6.18.0 release notes — prisma init now creates a prisma.config.ts automatically · 2025-10-22 · Prisma 6.13.0 release notes — prisma.config.ts moves to General Availability · 2025-07-29

generator client { output }

New requirement in prisma 6.6.0 (2025-04-08) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The prisma-client generator — the one Prisma 7 documents and tells you to move to — refuses to run without an output path, exiting with "An output path is required for the prisma-client generator". That has been true since the generator arrived in 6.6.0, not since 7.0.0: the requirement is a property of the generator, not of the major. The older prisma-client-js generator is unchanged and still needs no output — with @prisma/client installed it writes into node_modules/@prisma/client and prints that path, on every release up to 7.10.0.

The stale belief: That output is an optional advanced setting, because for the whole of Prisma 1 through 6 the only generator was prisma-client-js and it defaulted into node_modules. It is still optional for that generator; it is required for the one Prisma 7 documents.

// Stale
generator client {
  provider = "prisma-client"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

Corrected 2026-09-08 against twenty-three installed releases from 6.0.0. Two clauses this row published were measured false and are withdrawn. "Prisma 7 does not generate the client into node_modules at all" is not what the shipped CLI does: a prisma-client-js block with no output prints "Generated Prisma Client (v7.10.0) to ..\node_modules\@prisma\client" at every 7.x release this Index covers, and the only thing that path needs is what Prisma 6 needed too — that @prisma/client be installed. With that package absent the CLI fails "Could not resolve @prisma/client", not with a missing-output error. The date was a major too late: at 6.5.0 the same prisma-client block exits "Error: spawn prisma-client ENOENT", the provider not existing, while 6.6.0 already refuses it for the missing output — naming the generator prisma-client-ts, the Early Access spelling, which is still an accepted provider at 7.10.0.

Reproduced against: Claude Fable 5 (S3), Claude Sonnet 5 (S3) — prisma/v1, 2026-08-31.

Source: prisma@6.6.0 shipped CLI — prisma generate over a prisma-client generator block with no output exits "An output path is required for the prisma-client-ts generator"; the same schema at 6.5.0 exits "Error: spawn prisma-client ENOENT" · 2025-04-08 · prisma@7.10.0 shipped CLI — a prisma-client-js generator block with no output prints "Generated Prisma Client (v7.10.0) to ..\node_modules\@prisma\client", and the prisma-client block still exits "An output path is required" · Upgrade to Prisma ORM 7 — Schema changes (the sentence this row measured, and found does not match the shipped CLI for prisma-client-js)

datasource db { url }

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

url and shadowDatabaseUrl are configured in prisma.config.ts in Prisma 7, and directUrl has been removed outright. If you used directUrl for migrations, put that value in the config file's url — that is the connection string the CLI uses for migrations.

The stale belief: That the datasource block in schema.prisma carries url, directUrl and shadowDatabaseUrl, read from .env via env().

// Stale
datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  directUrl         = env("DIRECT_URL")
  shadowDatabaseUrl = env("SHADOW_URL")
}

// Current
datasource db {
  provider = "postgresql"
}

// and in prisma.config.ts:
//   datasource: { url: env('DATABASE_URL'), shadowDatabaseUrl: env('SHADOW_URL') }

Reproduced against: Claude Opus 5 (S3) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Schema changes · 2025-11-19

driver adapter class names

Renamed in prisma 7.0.0 (2025-11-19)

The driver adapter classes were renamed to a consistent casing in 7.0.0: PrismaBetterSQLite3 -> PrismaBetterSqlite3, PrismaD1HTTP -> PrismaD1Http, PrismaLibSQL -> PrismaLibSql, PrismaNeonHTTP -> PrismaNeonHttp.

The stale belief: The v6 spellings, which are what any model that learned driver adapters before 7.0.0 will emit.

// Stale
import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'

// Current
import { PrismaBetterSqlite3 } from '@prisma/adapter-better-sqlite3'

Reproduced against: Claude Opus 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Driver Adapter naming updates · 2025-11-19

prisma.config.ts engine key

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 31 releases, prisma 6.0.0 through 7.10.0

The engine: 'js' | 'classic' and adapter keys of prisma.config.ts were removed in 7.0.0, and what the removal breaks is the TYPE CHECK rather than the CLI: defineConfig's declared parameter rejects both names from 7.0.0 (TS2353, "does not exist in type 'PrismaConfig'"), while the CLI loads and validates the same file at 7.0.0 and 7.10.0 with the key ignored. engine existed only in the 6.18.0-6.19.x window, where a datasource in the config required it; adapter did not — the config type has declared it since 6.12.0 and accepted it on its own since 6.13.0, where the CLI also wants experimental: { adapter: true } beside it.

The stale belief: That a Prisma config file needs an engine key, and that adapter is configured there rather than passed to the client constructor.

// Stale
export default defineConfig({
  engine: 'classic',
  datasource: { url: env('DATABASE_URL') },
})

// Current
export default defineConfig({
  datasource: { url: env('DATABASE_URL') },
})

Corrected 2026-09-12 (JOURNAL/154), on the adapter clause and on the mechanism. Type-checked with tsc 5.9.3 (strict, skipLibCheck, nodenext) against each of the 31 stable minors from 6.0.0 to 7.10.0, every rung's own packages under their real names. engine: not a declared key on 6.5.0-6.17.0, accepted on 6.18.0-6.19.0, rejected by name again from 7.0.0 — the fact's window, exactly. adapter: rejected by name on 6.5.0-6.11.0, DECLARED from 6.12.0 (where the object then fails for a missing earlyAccess, not for the key), accepted alone on 6.13.0-6.17.0, still declared but requiring engine on 6.18.0-6.19.0, and rejected by name from 7.0.0 — so "they existed only in the 6.18.0-6.19.x window" was true of one key and false of the other by six minors. Below 6.5.0 the prisma manifest declares no ./config export at all, so there is no module to check. FOUND, and no release note says it: the top-level adapter key is in the config type at 6.12.0 (2025-07-15), a release before the 6.13.0 note that introduces it — the 6.12.0 note adds migrations and views and does not mention adapters. The severity survives for a reason the original statement did not give: the stale file fails tsc at every 7.x rung, which is a build failure, but it passes prisma validate at 7.0.0 and 7.10.0 (JOURNAL/153), so a project with no type-check step never sees it. WITHDRAWN with this correction: the claim that the key dates code to a 28-day window between 2025-10-22 and 2025-11-19. 6.19.x patches were published until 2026-04-01, so engine was readable for far longer than its minor's own month, and adapter was readable from 6.12.0. CLI SHADOW MEASURED 2026-09-12 (JOURNAL/170, via LF7i): what 6.18.0/6.19.0 do to a config datasource with no engine beside it is not a refusal. prisma db pull on a project whose url is in both the config and the schema dials the CONFIG's host with engine: "classic" present and the SCHEMA's host without it, on both rungs — so the requirement this statement gives from the type side is enforced at the CLI by dropping the key, which a reader who never type-checks the file sees as the config's datasource having no effect at all.

Reproduced against: Claude Opus 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Schema and config file updates · 2025-11-19 · Prisma 6.18.0 release notes — Support for defining your datasource in prisma.config.ts · 2025-10-22 · Prisma 6.13.0 release notes — Prisma Config file General Availability · 2025-07-29

@prisma/client-runtime-utils

New requirement in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

If you stay on the prisma-client-js provider in Prisma 7 while using the now-required output option, you must install @prisma/client-runtime-utils as well. It is a new package with no v6 equivalent, so nothing trained before 2025-11-19 will mention it.

The stale belief: That prisma and @prisma/client are the only two packages a Prisma project needs.

npm install @prisma/client-runtime-utils   # prisma-client-js users only

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Generated Client and types move out of node_modules · 2025-11-19

/wasm export path

Renamed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

For prisma-client-js users, the /wasm export was renamed to /edge, and /edge changed meaning: it now means edge JS runtimes (Cloudflare, Vercel Edge) rather than Prisma Accelerate.

The stale belief: That @prisma/client/edge is the Accelerate entry point and @prisma/client/wasm is the edge-runtime one — the v5/v6 arrangement.

// Stale
import { PrismaClient } from '@prisma/client/wasm'

// Current
import { PrismaClient } from '@prisma/client/edge'

SCOPED 2026-09-02 (JOURNAL/038), against both generators. @prisma/client/edge carries a PrismaClient export only for projects still on the prisma-client-js generator, whose output is written into node_modules/.prisma/client — edge.d.ts is nothing but export * from '.prisma/client/edge'. Generate with the prisma-client generator that LF4 and LF6 prescribe and node_modules/.prisma is never created, so this import fails with TS2305, no exported member. Both directions were generated and type-checked on 7.0.0. If you are on the current generator there is no /edge entry point at all: import from your own generated output and reach the edge runtime through a driver adapter. The rename this entry records is real — /wasm is gone from the 7.0.0 export map — but it is a rename inside the deprecated path.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Miscellaneous · 2025-11-19 · @prisma/client 7.0.0, shipped package — edge.d.ts

accelerateUrl

Added in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

Accelerate users pass accelerateUrl to the constructor instead of an adapter, and keep the withAccelerate() extension. Do not pass a prisma:// or prisma+postgres:// URL to a driver adapter — PrismaPg expects a direct connection string and will fail on it.

The stale belief: That Accelerate is configured purely by putting the prisma:// URL in DATABASE_URL and adding the extension, with no constructor option.

// Stale
const prisma = new PrismaClient().$extends(withAccelerate())

// Current
const prisma = new PrismaClient({
  accelerateUrl: process.env.DATABASE_URL!,
}).$extends(withAccelerate())

CORRECTED 2026-09-02 (JOURNAL/038), against the generated client. The API claim holds — accelerateUrl is a declared constructor option — but the snippet as published did not compile under strict: process.env.DATABASE_URL is string | undefined and accelerateUrl is declared string, so a reader copying it got TS2345. The non-null assertion is now in the code. Reproduced identically on 7.0.0 and 7.10.0. The declaration also settles a second point the entry did not state: accelerateUrl and adapter are mutually exclusive (each is ?: never in the other's arm of the union), so an Accelerate client does not take a driver adapter as well.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — For Prisma Accelerate users · 2025-11-19 · Upgrade to Prisma ORM 7 — Prisma Accelerate · prisma 7.0.0, shipped package — generated PrismaClientOptions

ESM and toolchain minimums

New requirement in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

Prisma 7 ships as an ES module and requires Node >= 20.19.0 and TypeScript >= 5.4.0. Set "type": "module" in package.json, and module/moduleResolution to ESNext/bundler in tsconfig.json.

The stale belief: That Prisma is CommonJS and drops into any Node project without touching package.json or tsconfig.json.

{
  "type": "module"
}

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Upgrade to Prisma ORM 7 — ESM support / Prerequisites

metrics preview feature

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The deprecated metrics preview feature was removed in 7.0.0. Read pool metrics from the underlying driver instead — for example the pg pool.

The stale belief: That previewFeatures = ["metrics"] plus prisma.$metrics.json() is how you instrument a Prisma app.

// Stale
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["metrics"]
}

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Deprecated metrics feature has been removed · 2025-11-19

new PrismaClient({ datasources })

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The datasources constructor option is gone. Overriding the connection string at construction time is done by configuring the driver adapter you now have to pass anyway.

The stale belief: That new PrismaClient({ datasources: { db: { url } } }) is how you point one client at a different database — the documented override for the whole v2-v6 era.

// Stale
const prisma = new PrismaClient({
  datasources: { db: { url: process.env.DATABASE_URL } },
})

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

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Prisma Client changes · 2025-11-19

new PrismaClient({ datasourceUrl })

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The datasourceUrl constructor option, added in 5.2 as the shorthand for datasources, was removed in 7.0.0 along with it. Pass the connection string to the driver adapter instead.

The stale belief: That datasourceUrl is the current shorthand for overriding the connection string at runtime.

// Stale
const prisma = new PrismaClient({ datasourceUrl: process.env.DATABASE_URL })

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

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Prisma Client changes · 2025-11-19

prisma introspect

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The deprecated prisma introspect command was removed in 7.0.0 — prisma db pull is the only spelling. db pull also lost its undocumented --local-d1 flag at 7.0.0 and has not regained it. Its --url flag is a two-release window rather than a removal: accepted throughout 6.x, rejected at 7.0.0 and 7.1.0, and accepted again from 7.2.0, where it is documented for the first time (see LF34).

The stale belief: That prisma introspect still exists as an alias, which it did (deprecated) from 3.0 through 6.x.

# Stale
npx prisma introspect

# Current
npx prisma db pull

Restated 2026-09-08 over twenty-three installed releases from 6.0.0. The --url clause this row published as a removal is the lower half of a window whose upper edge the Index already published as LF34, and neither row cited the other: passing the flag shows it accepted at every 6.x rung, rejected at 7.0.0 and 7.1.0, and accepted again from 7.2.0 — LF34's own date. Measured by passing the flag, not by reading --help — --url is absent from 6.19.0's help table and present in 7.10.0's, the opposite of what those releases actually accept. The introspect and --local-d1 clauses are contiguous from 7.0.0 and unchanged. Second pass 2026-09-08 (BACKLOG 11k-t-ii-i-d): LF34's clauses now pass the flag too, through the same shared helper this row uses, because two rows that are complements on one ladder must not be able to drift apart. The same pass measured the other two commands the release note names — db push --url and migrate dev --url are rejected at every rung from 6.0.0 to 7.1.0 — so this window belongs to db pull alone, and it is not a general 7.0.0 removal of the flag.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Miscellaneous · 2025-11-19

generator client { runtime }

Renamed in prisma 6.15.0 (2025-08-27) · boundary measured on 28 releases, prisma 6.0.0 through 7.10.0

From 6.15.0 the prisma-client generator refuses three runtime spellings it had accepted since its first release, 6.6.0: vercel is now vercel-edge, node is now nodejs, and deno-deploy is now deno. prisma generate stops with Unknown target runtime: "vercel" and exits 1, on every release from 6.15.0 through 7.10.0. The values accepted from 6.15.0 are nodejs, deno, bun, workerd (alias cloudflare), vercel-edge (alias edge-light) and, on 6.x only, react-native (LF14). vercel-edge is itself refused on 6.6.0 through 6.14.x, so it does not work on both sides of the change. edge-light, nodejs and deno do: each generates on every release from 6.6.0, and each builds the same client as the spelling it replaces. deno-deploy also changed meaning one release before it was removed. Through 6.13.x it built the edge client, the one workerd builds. At 6.14.x it built the Node client, the one deno builds, and the 6.14.0 release note does not mention the change. A schema that got the edge build from deno-deploy on 6.13 or earlier gets the Node build from deno. The prisma-client-js generator does not read runtime at all.

The stale belief: That the prisma-client generator spells Vercel's Edge runtime vercel, Node's node and Deno Deploy's deno-deploy, the spellings it accepted from 6.6.0 through 6.14.x.

// Stale
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
  runtime  = "vercel" // refused from 6.15.0: Unknown target runtime: "vercel"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
  runtime  = "vercel-edge" // 6.15.0 and later. "edge-light" builds the same client on 6.6.0 and later.
}

Written 2026-09-11 (JOURNAL/152) from execution, with the 6.15.0 release note read first. The five releases 6.11.0-6.15.0 were installed for this fact (one directory per release, resolved alone), so every row is measured on 28 rungs, 6.0.0-7.10.0, and the boundary sits between two adjacent releases. Each row runs prisma generate over a prisma-client generator with the value under test. What a value selects is read off the generated client as the set of @prisma/client/runtime/... modules it imports, compared on the same rung with what workerd builds (the edge client: runtime/edge on 6.x, runtime/wasm-compiler-edge on 7.x) and what no runtime builds (the Node client). LF37a (vercel-edge builds the edge client) and LF37b-d (vercel, node and deno-deploy refused by name) rise at 6.15.0. LF37e (vercel builds the edge client and node the Node client) holds from 6.6.0 up to 6.15.0. LF37f (deno-deploy builds the edge client) holds from 6.6.0 up to 6.14.0. LF37g (deno-deploy builds the Node client, the same imports as deno) holds at 6.14.0 only. LF37h (edge-light builds the edge client, nodejs and deno the Node client) holds from 6.6.0, the generator's first release. Below 6.6.0 no value generates, because the provider does not exist (spawn prisma-client ENOENT). The shipped CLI says the same: 6.13.0's switch has case"edge-light":case"vercel":return"edge-light" and puts deno-deploy in the edge group, 6.14.0 has case"deno":case"deno-deploy":return"deno", and 6.15.0 has case"edge-light":case"vercel-edge":return"vercel-edge" with no vercel, node or deno-deploy case. The input is lower-cased before the switch on all three. The refusal message's list of options is not the accepted set: vercel and node are never printed on 6.6.0-6.14.0 though both generate, and 6.14.0's list omits cloudflare, which also generates. The stale_code and correct_code were run as written (inside a schema with a datasource block and one model) on all 28 rungs. The stale block generates on 6.6.0-6.14.0 and is refused from 6.15.0. The correct block is refused on 6.6.0-6.14.0 and generates from 6.15.0.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma ORM 6.15.0 release notes — prisma-client: runtime improvements and schema flexibility · 2025-08-27 · prisma@6.14.0 shipped CLI, build/index.js: the target-runtime switch (compared with 6.13.0 and 6.15.0) · 2025-08-12 · Executed against the published packages (tools/audit/bisect-facts.mjs rows LF37a-LF37h, 28 rungs, 2026-09-11) · 2026-09-11

@@index([...], include: [...])

No release changed this · true on 23 releases executed, prisma 6.0.0 through 7.10.0

Prisma's @@index has no include: argument — there is no schema-level way to declare a PostgreSQL covering index (CREATE INDEX ... INCLUDE (...)). @@unique likewise has no nullsNotDistinct: argument. Both are rejected by the schema validator with No such argument. on every Prisma 7 release tested, 7.0.0 through 7.10.0: no release added them, so there is no version to upgrade to. This entry exists because 7.4.0 did add a new @@index/@@unique argument — where: (LF26) — and a model that has absorbed that fact can over-extend it into a family of index arguments that were never added. 7.4.0 dates the sibling that makes the trap live; it does not date anything about include:.

The stale belief: That because Prisma 7.4 extended @@index/@@unique with index-shaping arguments, it also accepts include: for covering-index payload columns, or nullsNotDistinct: on @@unique.

// Stale
model User {
  id    Int    @id @default(autoincrement())
  email String
  name  String

  @@index([email], include: [name])
}

// Current
// There is no schema-level covering index. Declare the plain index and add the
// INCLUDE clause in SQL, or widen the index key if the payload column is small.
model User {
  id    Int    @id @default(autoincrement())
  email String
  name  String

  @@index([email, name])
}

VERIFIED BY EXECUTION 2026-09-05, then across the whole ladder 2026-09-07. @@index([email], include: [name]) and @@unique([email], nullsNotDistinct: true) are each rejected by prisma validate with No such argument. at all eleven rungs from 7.0.0 to 7.10.0, while @@index([email], where: { deletedAt: null }) — the same position in the same file, the only difference being the argument name — validates from 7.4.0. So the rejection is about the argument and not about the schema around it. This is a NEGATIVE claim in the machine-checkable form (the tailwindcss LF30 / better-auth LF10 shape): the assertion is that the argument does not exist, and it is checked by the shipped validator's own enumeration of what it accepts rather than by the absence of a sentence in a changelog. Filed under introduced_in: 7.4.0 until 2026-09-08, which rendered as Added in prisma 7.4.0 directly above a statement saying the argument does not exist — the sibling's date standing in for a boundary this fact does not have. Now change_kind: "invariant" with a null version and the measured range (JOURNAL/080). Nothing below 7.0.0 was executed; the absence is not claimed for Prisma 6.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: prisma 7.10.0, shipped package — prisma validate on the stale_code schema above · Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support · 2026-02-11 · Bisected against the published packages, 11 rungs from 7.0.0 to 7.10.0 (tools/audit/bisect-facts.mjs, 2026-09-07) · 2026-09-07

Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

@prisma/sqlcommenter-query-insights

Added in prisma 7.1.0 (2025-12-04) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

Prisma ships a first-party SQLCommenter plugin. @prisma/sqlcommenter-query-insights appends query-insights metadata to statements as a trailing SQL comment, so queries seen in the database’s own statistics and log views can be attributed back to the application code that issued them. It plugs into the comments?: SqlCommenterPlugin[] option of the PrismaClient constructor, which prisma added in 7.1.0 (2025-12-03); the plugin's own first stable release is 0.0.1, published 2025-12-04, and its exported prismaQueryInsights() already returns a SqlCommenterPlugin there. The capability therefore dates to 2025-12-04, thirteen days before the 7.2.0 release note that announced it and from which the package's version line joins prisma's. Before that the only honest answer was to write the interception yourself at the driver-adapter layer, which is what every draw in this battery produced.

The stale belief: That Prisma’s first-party observability surface is OpenTelemetry tracing (@prisma/instrumentation) and metrics only, that SQLCommenter has adapters for Knex/Sequelize/pg but not Prisma, and that the ORM-generated SQL is therefore unreachable from application code.

// Stale
// wrap the driver adapter by hand and append the comment yourself
class CommentingPool extends Pool {
  query(config, values, cb) {
    const suffix = sqlcommenterSuffix()
    if (typeof config === "string") config += suffix
    else if (config?.text) config = { ...config, text: config.text + suffix }
    return super.query(config, values, cb)
  }
}

// Current
// the first-party plugin. Its own first release is 0.0.1 (2025-12-04); from
// 7.2.0 its version line follows prisma's. Needs prisma >= 7.1.0 for the
// `comments` option on the client.
// npm i @prisma/sqlcommenter-query-insights

The correction here is deliberately the package name and nothing more. This Index has not driven the plugin against a database, so it states that the package exists, what it is for and when it shipped, and does not put a configuration snippet in a subject’s mouth that it has not executed.

CORRECTED 2026-09-07 BY BISECT (JOURNAL/074). This row previously read “its first stable release is 7.2.0” with introduced_in: 7.2.0 / 2025-12-17, and its note dismissed the earlier 0.0.1 as “a placeholder” — an assumption read off a version number and never executed. 0.0.1 is a 38 KB published package with the same description, a dist/ tree, and a declaration reading export declare function prismaQueryInsights(): SqlCommenterPlugin whose doc comment already shows the exact new PrismaClient({ adapter, comments: [prismaQueryInsights()] }) usage. It was published 2025-12-04, one day after prisma 7.1.0 (2025-12-03) added the comments?: SqlCommenterPlugin[] socket it plugs into — that option is absent from @prisma/client 7.0.0's shipped runtime/client.d.ts and present from 7.1.0 on, bisected across eleven installed releases. So both halves of the capability existed on 2025-12-04, and introduced_on records that later date rather than 7.1.0's own. The three findings that charge on this fact are unaffected in kind: every subject's stated cutoff is months above either date.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2), Claude Sonnet 5 (S2) — prisma/v5-a, 2026-09-06; prisma/v5-c, 2026-09-06; prisma/v5-e, 2026-09-06.

Source: @prisma/sqlcommenter-query-insights 0.0.1, shipped package — dist/index.d.ts, installed and read 2026-09-07 · 2025-12-04 · @prisma/client 7.1.0, shipped package — runtime/client.d.ts; the option is absent at 7.0.0 · 2025-12-03 · Prisma ORM 7.2.0 release notes — SQL Commenter plugin (the announcement, thirteen days after the package shipped) · 2025-12-17

queryPlanCacheMaxSize

Added in prisma 7.8.0 (2026-04-22) · boundary measured on 31 releases, prisma 6.0.0 through 7.10.0

The PrismaClient constructor accepts queryPlanCacheMaxSize?: number, which bounds the query plan cache. Passing 0 disables the cache entirely; omitting the option uses the default size. The runtime takes it from 7.8.0: below that release the constructor rejects it by name (Unknown property queryPlanCacheMaxSize provided to PrismaClient constructor), and at 7.8.0 and above it is accepted. It is an ordinary documented optional property — not an internal, and not an environment variable — of the client the prisma-client generator emits, where it is declared on the shared PrismaClientBaseOptions with the release note's own example in its doc comment. But "the client options type" names two types here, and only one of them has the option. prisma also ships the prisma-client-js generator, deprecated at 7.0.0 and still generating at 7.10.0, whose emitted client declares its own flat interface PrismaClientOptions — errorFormat, log, transactionOptions, adapter, accelerateUrl, omit — which never gained the option. Against that client, at every release measured through 7.10.0, passing it is a TypeScript excess-property error even though the runtime underneath accepts it.

The stale belief: That the query plan cache is an internal detail of the query compiler with no user-facing size or disable knob, so the only lever on its memory use is reducing the number of distinct query shapes — and, in the stronger form, that passing queryPlanCacheMaxSize is an excess-property type error or makes the constructor throw on an unknown key. READ THE NOTE BEFORE SCORING THE STRONGER FORM: both of its halves are measured TRUE somewhere on this ladder. PrismaClient does validate its options and does throw on an unknown property, naming it, at all 31 releases (LF33d); it throws for THIS key below 7.8.0 (LF33c); and the excess-property error is what the legacy generator's client gives at every release, 7.10.0 included (LF33b). What is wrong at 7.8.0 and above, and all this fact charges, is the claim that the option does not exist.

// Stale
// the stronger form of the belief, offered when reviewing working code:
// "PrismaClient validates its options and throws on unknown keys,
//  so this line would fail at construction time"
const prisma = new PrismaClient({ adapter })

// Current
const prisma = new PrismaClient({
  adapter,
  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely
})

VERIFIED BY TYPE DECLARATION 2026-09-06. @prisma/client runtime/client.d.ts has no occurrence of queryPlanCacheMaxSize at 7.4.0, 7.5.0, 7.6.0 or 7.7.0, and declares it at 7.8.0 and 7.10.0 with a documentation comment and a usage example. The bisection matters here because the cache is older than the option: query plan caching is a 7.4.0 feature — it is the attribution anchor in prompts/prisma.md § v2 — so a model can know the cache exists and still be four releases behind on whether it can be sized. EXECUTED 2026-09-12 ON 31 RUNGS AGAINST BOTH GENERATORS AND AGAINST THE RUNTIME (BACKLOG 1h-n-v, JOURNAL/160). THE DATE DID NOT MOVE — four independent instruments all put the boundary at 7.8.0, contiguous — BUT THE STATEMENT DID, AND SO DID THE SCORING ADVICE. (a) The declaration the 2026-09-06 reading greps is the runtime bundle's INTERNAL client.d.ts, which is not what a reader writes against; prisma emits two of those and they disagree. LF33a asks the client the documented prisma-client generator emits and agrees: 7.8.0, blind below 6.8.0 (no such generator below 6.6.0, and 6.6.0/6.7.0 emit a client this program cannot compile). LF33b asks the legacy prisma-client-js generator and is FLAT FALSE — the identifier occurs nowhere in its emitted tree at any of the 31 releases, and a construction naming the key beside an adapter is TS2322 against that client at 7.10.0. (b) The RUNTIME had never been executed at all, and it is the half the two findings charged on this fact made a claim about. LF33c executes it and finds the same 7.8.0 with NO blind rungs: below it the construction throws Unknown property queryPlanCacheMaxSize, at and above it the option is taken and the only complaint left is the missing adapter. LF33d is its control and is the row that changes how a draw should be read: the constructor rejects an INVENTED property by name at all 31 releases, so "PrismaClient validates its options and throws on unknown keys" — the mechanism both charged subjects asserted — is simply correct, and a finding must not be read as penalising it. ONE CONFOUND WORTH RECORDING, because it had the type rows backwards before a control was put beside them: under prisma-client at 7.x the constructor requires an options bag carrying adapter, so new PrismaClient({ queryPlanCacheMaxSize: 0 }) is a TS2345 about the MISSING ADAPTER, which reads as "the key is rejected" to any instrument that only checks the exit code. Adding adapter removes that at 7.x and introduces it below 6.16.0, where adapter is itself unknown (LF38) — no single construction is clean across the ladder, which is why the two type rows ask the question at the type level instead.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.8.0 release notes — Prisma Client features · 2026-04-22 · @prisma/client 7.8.0, shipped package — runtime/client.d.ts · prisma 7.10.0, generator output — prisma-client internal/prismaNamespace.ts vs prisma-client-js index.d.ts · prisma 7.10.0 and 7.7.0, executed — generator output and constructor validation

prisma bootstrap

Added in prisma 7.7.0 (2026-04-07) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The Prisma CLI has a bootstrap command that sequences the whole Prisma Postgres setup in one interactive flow: init or scaffold from one of ten starter templates, link to a database, install missing dependencies, run migrate dev, run generate, and run db seed. It detects project state and runs only the steps that are needed, prompts before each side-effecting step, and skips completed steps when re-run. It takes --template, and a non-interactive --api-key / --database form for CI.

The stale belief: That there is no single Prisma command that walks the whole setup, and that a new project always needs a hand-assembled sequence of npm install, prisma init, prisma migrate dev, prisma generate and prisma db seed.

# Stale
# offered as "the whole path", with the claim that no single command exists:
npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg
npx prisma init --db
npx prisma migrate dev --name init
npx prisma db seed

# Current
npx prisma@latest bootstrap
# with a starter template:
npx prisma@latest bootstrap --template nextjs
# non-interactive, for CI:
npx prisma@latest bootstrap --api-key "$PRISMA_API_KEY" --database "db_abc123"

VERIFIED BY EXECUTION 2026-09-06. prisma --help was run from the shipped CLI at 7.4.0 through 7.10.0. bootstrap Bootstrap a Prisma Postgres project is absent from the command table at 7.6.0 and present at 7.7.0, which pins the introducing release from the artifact. The workaround sequence in stale_code does work, so this is a false claim about what the CLI offers rather than broken code — S2.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.7.0 release notes — prisma bootstrap command · 2026-04-07 · prisma 7.7.0, shipped package — output of prisma --help

new PrismaPg(connectionString)

Added in prisma 7.6.0 (2026-03-27) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

new PrismaPg(...) accepts a bare PostgreSQL connection string as its first argument. The constructor signature widened from pg.Pool | pg.PoolConfig to pg.Pool | pg.PoolConfig | string in 7.6.0. The object form still works and is not deprecated; the point is that the string form is not an error.

The stale belief: That PrismaPg takes only a pg.Pool or a pg.PoolConfig-shaped object, so a bare connection string is a type error that has to be wrapped as { connectionString }.

// Stale
// offered as a correction to working code:
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })

// Current
// both of these compile at 7.6.0 and later:
const adapter = new PrismaPg(process.env.DATABASE_URL!)
const adapter2 = new PrismaPg({ connectionString: process.env.DATABASE_URL })

VERIFIED BY TYPE DECLARATION 2026-09-06. @prisma/adapter-pg was installed at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0. dist/index.d.ts declares constructor(poolOrConfig: pg.Pool | pg.PoolConfig, options?: PrismaPgOptions | undefined) at 7.4.0 and 7.5.0, and constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined) at 7.6.0 through 7.10.0. The added union member is the whole change and it is visible in the published declaration file, so the introducing release is pinned by the artifact rather than by the note. The object form the stale belief insists on is itself correct code, so this is a false claim about a limit and not a broken replacement — S2.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.6.0 release notes — Driver Adapters · 2026-03-27 · @prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts

prisma postgres link

Added in prisma 7.6.0 (2026-03-27) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The Prisma CLI has a postgres command group, and its first member is prisma postgres link, which connects an existing local project to an already-provisioned Prisma Postgres database. Before 7.6.0 there was no such command and attaching a project to an existing database was a manual DATABASE_URL edit. prisma postgres --help at 7.6.0 through 7.10.0 lists exactly one subcommand: link.

The stale belief: That the Prisma CLI has no command for attaching a project to an already-provisioned Prisma Postgres database, and that prisma init --db (which creates a new one) plus a hand-edited .env is the only route.

# Stale
# the workaround, still offered as though it were the only option:
# 1. copy the connection string out of the Prisma Console by hand
# 2. paste it into .env as DATABASE_URL
npx prisma db pull
npx prisma generate

# Current
npx prisma postgres link
# non-interactive:
npx prisma postgres link --api-key "$PRISMA_API_KEY" --database "db_abc123"

VERIFIED BY EXECUTION 2026-09-06. prisma --help was run from the shipped CLI at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 in a scratch directory. The postgres entry is absent from the command table at 7.5.0 and present at 7.6.0, which pins the introducing release without relying on the release note. prisma postgres --help at 7.6.0+ prints link Link a local project to a Prisma Postgres database and no other subcommand — which is also what makes prisma postgres branch a safe poison rung. The workaround in stale_code does work, and that is what keeps this S2 rather than S1.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.6.0 release notes — CLI · 2026-03-27 · prisma 7.6.0 and 7.10.0, shipped package — output of prisma postgres --help

statementNameGenerator

Added in prisma 7.6.0 (2026-03-27) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

@prisma/adapter-pg exposes statementNameGenerator, a PrismaPgOptions callback of type (query: SqlQuery) => string. The returned string is passed as the name property to pg.Client#query(), which is what makes node-postgres cache the underlying prepared statement. The shipped declaration states the default explicitly: with no generator provided, prepared statements are not cached.

The stale belief: That the Prisma pg adapter issues every query unnamed with no supported way to change that, so node-postgres statement caching can never engage and the only route to prepared-statement reuse is running the hot query through a separate pg pool alongside Prisma.

// Stale
// offered as the only route:
// run the hot query through your own pg Pool, outside Prisma, so you can set a name
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
await pool.query({ name: "hot-query", text: "SELECT ...", values: [] })

// Current
const adapter = new PrismaPg(process.env.DATABASE_URL!, {
  statementNameGenerator: (query) => "prisma_" + hashOf(query.sql),
})

VERIFIED BY TYPE DECLARATION 2026-09-06. dist/index.d.ts of the shipped @prisma/adapter-pg has no statementNameGenerator anywhere in PrismaPgOptions at 7.4.0 or 7.5.0, and declares it at 7.6.0 through 7.10.0 together with declare type StatementNameGenerator = (query: SqlQuery) => string. The documentation comment on the option carries the default behaviour, which is the part the stale belief gets right about 7.5.0 and wrong about 7.6.0.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.6.0 release notes — Driver Adapters · 2026-03-27 · @prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts

tx.$transaction()

Added in prisma 7.5.0 (2026-03-11) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

$transaction can be called on the interactive transaction client. It was removed from the client deny list in 7.5.0, which added nested transaction rollback via savepoints for SQL databases: if the outer transaction fails, the inner nested one is rolled back with it. The deny list constant itself is the evidence — it reads ["$connect", "$disconnect", "$on", "$transaction", "$extends"] at 7.4.0 and ["$connect", "$disconnect", "$on", "$use", "$extends"] at 7.5.0 and later.

The stale belief: That $transaction is on ITXClientDenyList, so tx.$transaction(...) is a type error and absent at runtime, and that manual SAVEPOINT / ROLLBACK TO SAVEPOINT through $executeRawUnsafe is the only way to nest.

// Stale
// offered as the only route, and as a correction to working code:
await prisma.$transaction(async (tx) => {
  await tx.$executeRawUnsafe("SAVEPOINT sp1")
  try {
    await tx.post.create({ data: { title: "hello", authorId: 1 } })
  } catch {
    await tx.$executeRawUnsafe("ROLLBACK TO SAVEPOINT sp1")
  }
})

// Current
await prisma.$transaction(async (tx) => {
  await tx.user.create({ data: { email: "a@example.com" } })
  await tx.$transaction(async (tx2) => {
    await tx2.post.create({ data: { title: "hello", authorId: 1 } })
  })
})

VERIFIED BY TYPE DECLARATION 2026-09-06. @prisma/client was installed at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 and runtime/client.d.ts read at each. declare const denylist contains "$transaction" at 7.4.0 and does not at 7.5.0 through 7.10.0, where "$use" stands in its place; ITXClientDenyList is defined as (typeof denylist)[number] and the interactive transaction client is Omit<..., ITXClientDenyList>, so removal from that one constant is exactly what makes tx.$transaction type-check. This is the type-level form of the 7.5.0 release note. The raw-SQL savepoint workaround still works, so a reader who follows the stale belief loses ergonomics rather than correctness — S2, not S1.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.5.0 release notes — Features · 2026-03-11 · @prisma/client 7.5.0, shipped package — runtime/client.d.ts

prisma db push --url

Added in prisma 7.2.0 (2025-12-17) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The datasource connection string can be passed to the schema-push and migration commands directly on the command line. 7.2.0 added --url to prisma db push and prisma migrate dev: on every release from 6.0.0 through 7.1.0 both commands reject it outright with unknown or unexpected option: --url, and from 7.2.0 both accept it and dial it, described in the help table as "Override the datasource URL from the Prisma config file". prisma db pull is named in the same release note and is the exception it does not draw: that command accepted --url throughout 6.x while listing it in no help table, lost it at 7.0.0 and 7.1.0, and regained it here — for db pull, 7.2.0 is where the flag was documented and restored, not where it was added, and LF16 carries the window. Before 7.2.0 db push and migrate dev took the URL only from the schema or prisma.config.ts, resolved from the process environment, so the standard advice was to prefix the command with an inline DATABASE_URL=. That advice still works and is not wrong; it is simply no longer the only option, and a model that denies the flag exists will not offer it.

The stale belief: That db push and migrate dev resolve the datasource only from configuration and the environment, and that the long-standing feature request for a URL flag on them is still open — true continuously from Prisma 2 through 7.1.0.

# Stale
DATABASE_URL="$EPHEMERAL_PG_URL" npx prisma db push --skip-generate --accept-data-loss

# Current
npx prisma db push --url "$EPHEMERAL_PG_URL" --skip-generate --accept-data-loss

Bisected against the shipped CLI over twenty-three installed releases from 6.0.0 by PASSING the flag, not by reading --help. RESOLVED 2026-09-08 (BACKLOG 11k-t-ii-i-d, JOURNAL/086): the OPEN question this row carried — whether db push --url and migrate dev --url behave on 6.x the way db pull --url does — is measured, and they do not. Both are rejected with unknown or unexpected option: --url at all twelve 6.x rungs and at 7.0.0 and 7.1.0, and accepted from 7.2.0, where the CLI dials the host passed to it: --url=postgresql://u:p@localhost:1/x produces Can't reach database server at localhost:1. So "added" is the right word for these two commands and the date holds. db pull is the one of the three with a pre-history, and it is larger than this note previously guessed: not merely prisma introspect --url in the 2.x era but db pull --url itself, accepted AND USED on every 6.x rung — pass it a different port and the command dials that port while the banner still echoes the schema's — and absent from that release's own help table throughout. Its shape is a window; the Index publishes it as LF16, whose probe is this row's exact complement and now shares its helper so the two cannot drift apart. The help table survives here as one clause and only one, LF34d, which is what "documented" rests on: db pull --help lists no --url at 6.19.0, 7.0.0 or 7.1.0 and lists it at 7.2.0. Reading that table as a claim about the flag is what made this row contradict its own sibling for a day. The three sibling commands that took a URL throughout, and which subjects reliably name instead, are db execute --url, migrate diff --from-url and migrate diff --to-url. What a reader acts on is unchanged and so is the charge: subjects deny the capability exists at all on db push and migrate dev, which is the pair this row now states.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v5-c, 2026-09-06; prisma/v5-e, 2026-09-06.

Source: Prisma ORM 7.2.0 release notes · 2025-12-17 · prisma@7.2.0 shipped CLI — prisma db push --help lists --url Override the datasource URL from the Prisma config file; the same table at 7.1.0 does not · 2025-12-17 · prisma@6.19.0 shipped CLI — db push --url=... and migrate dev --url=... are rejected with unknown or unexpected option: --url, while db pull --url=... is accepted and dialled and appears in no help table; measured at every 6.x minor from 6.0.0 · 2025-11-05

automatic .env loading

Behaviour changed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The Prisma CLI no longer loads .env files by itself. Load them yourself — import 'dotenv/config' at the top of prisma.config.ts is the vendor's own example.

The stale belief: That putting DATABASE_URL in .env is enough for prisma migrate to find it, which it was for the whole v2-v6 era — no load step anywhere in the project.

import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'

export default defineConfig({ datasource: { url: env('DATABASE_URL') } })

Reproduced against: Claude Fable 5 (S2), Claude Sonnet 5 (S2) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Explicit loading of environment variables · 2025-11-19

@@index([...], where: ...) / @@unique([...], where: ...)

Added in prisma 7.4.0 (2026-02-11) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

Prisma can express a partial (filtered) index in the schema since 7.4.0. Put partialIndexes in previewFeatures and pass where: to @@index or @@unique. Two predicate forms are accepted: a type-safe object literal, which supports only field equality and not ({ published: true }, { deletedAt: { not: null } } — no gt/lt/in, no AND/OR), and raw("...") for any connector-specific SQL predicate. Supported on PostgreSQL, SQLite, SQL Server and CockroachDB; the schema validator rejects a where: index on MySQL with "Partial indexes (with a where clause) are not supported by the current connector".

The stale belief: That Prisma's schema language cannot express a partial or filtered index at all, so the only route is a hand-written CREATE INDEX ... WHERE ... inside a migration file (or prisma db execute), leaving the index invisible to schema.prisma.

// Stale
// stale: the schema cannot express it, so hand-write it in the migration
model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?

  @@index([email])
}
// then, in migrations/xxxx/migration.sql, by hand:
// CREATE INDEX "User_email_live_idx" ON "User"("email") WHERE "deletedAt" IS NULL;

// Current
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["partialIndexes"]
}

model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?
  active    Boolean   @default(true)

  @@index([email], where: { deletedAt: null })
  @@unique([email], where: { active: true })
  // richer predicates go through raw():
  // @@index([email], where: raw("\"deletedAt\" IS NULL AND active"))
}

VERIFIED BY EXECUTION 2026-09-05, both halves of the standing rule. Introducing evidence by bisection against the shipped CLI, not from the release note alone: at prisma@7.3.0 the validator answers The preview feature "partialIndexes" is not known. Expected one of: fullTextSearchPostgres, nativeDistinct, postgresqlExtensions, relationJoins, schemaEngineDriverAdapters, shardKeys, strictUndefinedChecks, views — the name is absent from its own enumeration. At prisma@7.4.0 the same enumeration contains partialIndexes and the schema above validates. There are no 7.3.x patch releases, so the boundary is exactly 7.3.0 (2026-01-21) -> 7.4.0 (2026-02-11). Current behaviour re-verified at prisma@7.10.0, the newest stable: the same schema is valid, on @@index and @@unique. Poison controls confirm the validator can fail rather than accepting anything: previewFeatures = ["partialIndexesXYZ"] is rejected as unknown, where: { nosuchfield: null } is rejected as Field 'nosuchfield' does not exist in model 'User', and dropping the preview feature is rejected with Partial indexes are a preview feature. The object form's limits were found the same way — where: { score: { gt: 10 } } is rejected with Unknown key 'gt' in nested where clause object. Only 'not' is supported, and where: { AND: [...] } with Field 'AND' does not exist in model 'User'. Connector gating checked directly: valid on postgresql and sqlite, rejected on mysql. Still a preview feature at 7.10.0 — the generator block opt-in is required and is the part a model that half-remembers this will omit.

Reproduced against: Claude Opus 5 (S2) — prisma/v2-a, 2026-09-05.

Source: Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support · 2026-02-11 · prisma 7.4.0, shipped package — build/prisma_schema_build_bg.wasm · prisma 7.10.0, shipped package — prisma validate on the correct_code schema above

compilerBuild

Added in prisma 7.3.0 (2026-01-21) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The prisma-client generator takes a compilerBuild option with two values, "fast" (the default) and "small". It selects which build of the query compiler is embedded in the generated client, and it is the size/speed dial for size-constrained runtimes. A model that denies it exists sends you to bundler-side workarounds — trimming binaryTargets, marking the client external, pruning models — none of which is the option that was built for this.

The stale belief: That the generator has no size/speed dial at all, and that the only real lever on generated-client size is dropping the Rust query engine via queryCompiler plus driverAdapters — which is a different change, was already the default in 7.0.0, and is not a trade of speed against size.

// Stale
generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}

// Current
generator client {
  provider      = "prisma-client"
  output        = "../src/generated/prisma"
  compilerBuild = "small" // "fast" | "small"
}

Bisected against the shipped package: the string compilerBuild does not occur anywhere in prisma@7.2.0’s build/index.js and does occur in prisma@7.3.0’s.

Reproduced against: Claude Opus 5 (S2) — prisma/v5-c, 2026-09-06.

Source: Prisma ORM 7.3.0 release notes — new compilerBuild generator option · 2026-01-21 · prisma@7.3.0 shipped CLI — compilerBuild present in build/index.js; absent from prisma@7.2.0 · 2026-01-21

postinstall prisma generate

Removed in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

Prisma 7 runs nothing implicitly. The postinstall hook no longer runs prisma generate, and prisma migrate no longer runs generate or the seed script. Any Dockerfile or CI pipeline that relied on install-time generation produces an image with no client.

The stale belief: That npm install generates the client through Prisma's postinstall hook, so a Dockerfile needs no explicit generate step.

# Stale
RUN npm ci        # generated the client via postinstall, through v6
RUN npm run build

# Current
RUN npm ci
RUN npx prisma generate
RUN npm run build

This is the failure that passes locally and fails in CI: a developer who ran prisma generate by hand still has the output on disk.

Reproduced against: Claude Sonnet 5 (S2) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removal of implicit Prisma commands · 2025-11-19

enum member @map

Behaviour changed in prisma 7.3.0 (2026-01-21) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

Prisma reverted the 7.0.0 mapped-enum change in 7.3.0. From 7.3.0 onward the generated enum object maps each member name to itself again — PaymentProvider.MixplatSMS is the string 'MixplatSMS' — and the @map value is the database value, which the generated client does not expose. The mapped values appear in the generated object for 7.0.0, 7.1.0 and 7.2.0 only. If you need the database string in application code on 7.3.0+, keep your own map; there is no generated export that carries it.

The stale belief: That @map on an enum member changes what the generated client hands your code, so PaymentProvider.MixplatSMS === 'mixplat/sms'. That was true of 7.0.0, 7.1.0 and 7.2.0, and it is what the 7.0.0 release notes still say. It is false at every release from 7.3.0 on, and it was false before 7.0.0.

// Stale
export const PaymentProvider = {
  MixplatSMS: 'mixplat/sms',
  InternalToken: 'internal/token',
  Offline: 'offline'
} as const

// Current
export const PaymentProvider = {
  MixplatSMS: 'MixplatSMS',
  InternalToken: 'InternalToken',
  Offline: 'Offline'
} as const

CORRECTED 2026-09-03 (JOURNAL/048), and this fact was wrong in the direction that matters: it stated the 7.0.0 behaviour as current and was verified from the 7.0.0 release note alone, never from a generated client. Prisma reverted at 7.3.0. Verified by generating a client from one schema at four releases with prisma 7.0.0, 7.2.0, 7.3.0 and 7.10.0 installed: 7.0.0 and 7.2.0 emit the mapped values, 7.3.0 and 7.10.0 emit the member names. Three charged S2 findings rested on the old wording and are RETRACTED — opus-5 F5, sonnet-5 F12, fable-5 F11 — because all three subjects wrote the member-name form, which is correct for the release that was current when they were scored. The earlier note on this fact stands as history: AUDIT 2026-09-02 (JOURNAL/038) corrected code_lang from ts to prisma; both code blocks are generated TypeScript again now, so it is ts.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.3.0 release notes — Revert @map enums to v6.19.0 behavior (PR #29002) · 2026-01-21 · prisma 7.10.0 — client generated from a schema with @map on every enum member · prisma 7.2.0 — the same schema, the last release before the revert · Prisma 7.0.0 release notes — Mapped enums, the change that was later reverted · 2025-11-19

connection pool defaults

Default changed in prisma 7.0.0 (2025-11-19)

Pooling is the driver's, not Prisma's. Driver adapters use the underlying Node driver's pool settings, which differ from Prisma 6's: pg has no connection timeout by default (0) where Prisma 6 used five seconds. Connection-string parameters like connection_limit are not what tunes this any more.

The stale belief: That ?connection_limit=5&pool_timeout=10 on the datasource URL controls the pool, and that Prisma's own five-second connection timeout applies.

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
  max: 5,
  connectionTimeoutMillis: 5000,
})

The adapter option names are the underlying driver's; the example above is pg's.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Upgrade to Prisma ORM 7 — Driver adapters

Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

provider = "prisma-client-js"

Deprecated in prisma 7.0.0 (2025-11-19) · boundary measured on 23 releases, prisma 6.0.0 through 7.10.0

The generator provider Prisma 7 documents, and tells you to move to, is prisma-client — the Rust-free ESM client. It is not a default: there is no default provider in either major. A generator block that omits provider is rejected with "Argument provider is missing in generator block" on every release measured, 6.0.0 and 7.10.0 alike, so a schema that leaves it out does not fall back to the new generator — it fails to validate. prisma-client-js still works and is still accepted at 7.10.0, but the vendor states it will be removed in a future release, and using it together with an output path needs an extra package, @prisma/client-runtime-utils (see LF22).

The stale belief: That prisma-client-js is the only generator provider, which was true until the prisma-client generator arrived in 6.6.0.

// Stale
generator client {
  provider = "prisma-client-js"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

Corrected 2026-09-08. This row published "prisma-client is the default generator provider in Prisma 7", and there is no such default: the omitted-provider schema is rejected identically at all twenty-three installed releases from 6.0.0 to 7.10.0. Its stale-belief line also named 6.16.0 as the generator's arrival; the measured arrival is 6.6.0, the first release whose CLI knows the provider at all (see LF4). What the 7.0.0 on this row dates is the vendor's deprecation announcement, which has no executable shadow — the CLI accepts prisma-client-js and prints no deprecation warning for it at 7.0.0 or at 7.10.0.

Reproduced against: Claude Fable 5 (S3), Claude Sonnet 5 (S3) — prisma/v1, 2026-08-31.

Source: Upgrade to Prisma ORM 7 — Schema changes · Prisma 7.0.0 release notes — ESM Prisma Client as the default · 2025-11-19 · prisma@7.10.0 shipped CLI — prisma validate over a generator block with no provider exits P1012 "Argument provider is missing in generator block client", the same error the 6.0.0 CLI gives

previewFeatures = ["driverAdapters"]

Added in prisma 6.16.0 (2025-09-10) · boundary measured on 31 releases, prisma 6.0.0 through 7.10.0

Driver adapters are not a preview feature. From 6.16.0 the generated client's options type accepts adapter with nothing in previewFeatures; below 6.16.0 the same construction is TS2353 ("adapter does not exist in type") unless the schema carries previewFeatures = ["driverAdapters"]. Both stale flags are still ACCEPTED — driverAdapters validates at every release from 6.0.0 to 7.10.0 and queryCompiler at every release from 6.7.0 — so a schema that still lists them builds; they are a vestige, not an error. The 6.16.0 release note's own spelling of the first one, driverAdapter, is not a preview-feature name at any release this Index covers.

The stale belief: That using a driver adapter means opting into a preview feature — the Rust-free client's queryCompiler + driverAdapters era of 6.7.0 to 6.15.0 — so any schema that uses one has to declare the flags, and adapters are not production-ready.

// Stale
generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

Measured 2026-09-12 (JOURNAL/158) with tsc 5.9.3 (strict, nodenext, skipLibCheck) against a client generated on each of the 31 stable minors from 6.0.0 to 7.10.0, and the flag is the only thing that moves: new PrismaClient({ adapter }) type-checks from 6.16.0 with no previewFeatures at all, and on EVERY rung from 6.0.0 when the same schema carries previewFeatures = ["driverAdapters"]. Read from both generators: 6.16.0 under prisma-client-js on all thirty-one rungs, and 6.16.0 again under prisma-client, which can answer only from 6.8.0 up. What is measured here is the TYPE — that the key is accepted, not that a query runs; this Index has no database on the ladder. The 6.16.0 note that announces the change also asks for engineType = "client" in the generator block to opt into the Rust-free ORM, which is a separate claim and is not measured here. The severity is S3 rather than S1 because the stale schema still validates: the cost of the stale belief is a line of dead configuration and, for a reader, the impression that adapters are experimental.

Reproduced against: Claude Sonnet 5 (S3) — prisma/v6-a, 2026-09-12.

Source: Prisma 6.16.0 release notes — Rust-free ORM generally available · 2025-09-10

generator client { engineType }

Behaviour changed in prisma 7.0.0 (2025-11-19) · boundary measured on 31 releases, prisma 6.0.0 through 7.10.0

The engineType generator key is inert from 7.0.0 and was never removed. On every release from 7.0.0 to 7.10.0, engineType = "client", "library", "binary" and a value that does not exist all generate without error, and all four emit the same set of files as a schema carrying no engineType at all — the Rust-free client the 6.16.0 note told you to opt into is what 7.x generates unconditionally. The key last selected anything in the window 6.16.0 to 6.19.0, where engineType = "client" needs nothing in previewFeatures and emits the WebAssembly query compiler instead of runtime/library. Below 6.16.0 it is a hard prisma generate error unless previewFeatures = ["queryCompiler"] is present: 6.7.0 to 6.15.0 refuse it with "engineType = \"client\" requires enabling the queryCompiler preview feature", and 6.3.0 to 6.6.0 with "Unstable Feature: engineType=\"client\" is in a proof of concept phase". Three things are silent rather than loud. An unrecognised value is accepted at every release from 6.0.0 to 7.10.0 and emits the default client, so "it generated" never showed the value was honoured. An unrecognised KEY is accepted the same way: a generator block carrying a key Prisma ships at no release — engineMode, or a name nothing could mistake for one — generates on every release from 6.0.0 to 7.10.0 and emits the same files as a block that omits it, so nothing distinguishes a dead option from an invented one at the point of use. And prisma validate reports every one of these schemas valid at every release, including the ones prisma generate refuses outright.

The stale belief: That engineType = "client" is how you opt into Prisma's Rust-free client, so a Prisma 7 schema needs it — the instruction the 6.16.0 release note gives, for the window in which it was true — or, from an older cutoff, that it also needs previewFeatures = ["queryCompiler"] beside it.

// Stale
generator client {
  provider   = "prisma-client"
  output     = "../src/generated/prisma"
  engineType = "client"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

Measured 2026-09-12 (JOURNAL/164) on all 31 stable minors from 6.0.0 to 7.10.0, against BOTH generators — prisma-client-js and prisma-client — which agree on every boundary here. This fact is about the KEY; prisma LF14 is about the ENGINES the key named, and the two are not the same claim: LF14's "the client engines are gone" is true, and a reader who takes its stale_code (engineType = "binary") to mean the schema now fails is wrong — that schema generates silently on every 7.x release, and the only difference from omitting the key is that the CLI stops printing it. What the key selects is read off the set of files generation wrote and, for prisma-client, off the @prisma/client/runtime/* specifiers the generated client imports — never a file hash, because a generated client embeds the schema text and two values that build the same client hash differently (JOURNAL/134). A SECOND and independent instrument agrees on the 7.0.0 boundary: the CLI's own success line reads Generated Prisma Client (v6.19.0, engine=binary) on every release from 6.0.0 to 6.19.0 and names no engine from 7.0.0, which is the only signal a reader who does not diff the output directory would ever see. The severity is S3 rather than S1 because the stale schema still builds: the cost is a line of dead configuration, and — below 6.16.0 and without the flag — a build that fails for a reason the error message states exactly. AMENDED 2026-09-12 (BACKLOG 1h-n-vii, JOURNAL/166), in the session that designed the battery for this fact and needed the control: the unrecognised-KEY clause is LF39h, measured on the same 31 rungs by the committed bisector and INVARIANT at every one of them. It was added because prisma/v6 puts an invented generator key (engineMode) in front of four subjects, and a control that cannot say what the artifact does with that key is not a control — the answer is that the block builds and writes the default file set, which is why the battery grades what each line is SAID to do and never "did it generate". It is stated over two keys for LF39b's reason: one key cannot separate "passed through as third-party generator config" from "recognised and ignored".

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 6.16.0 release notes — Rust-free ORM and driver adapters are Generally Available · 2025-09-10 · Prisma 7.0.0 release notes — Removed Client Engines · 2025-11-19

Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

MongoDB support

Removed in prisma 7.0.0 (2025-11-19)

Prisma 7 does not support MongoDB. The vendor's instruction is to stay on Prisma 6 until support returns in a future v7 release. Advising a MongoDB user to install the latest version is advice that does not work.

The stale belief: That MongoDB is a first-class Prisma provider on every current version, as it was from 3.12 through 6.x.

This is the one case where the correct answer is to pin to the previous major. Prisma 6 is still receiving releases (6.19.3 shipped 2026-04-01). SCOPE, checked 2026-09-03 against an installed prisma 7.10.0: the toolchain does not refuse the provider. A schema with provider = "mongodb" passes prisma validate ("the schema is valid") and prisma generate emits a client. What is missing is the runtime: Prisma 7 connects through driver adapters and no MongoDB adapter is published — @prisma/adapter-mongodb is a 404 on the npm registry. So the failure arrives at connect time, not at generate time, and a reader who takes "does not support" to mean "the CLI will tell you" is wrong about where it breaks.

Reproduced against: Claude Fable 5 (S4), Claude Opus 5 (S4), Claude Sonnet 5 (S4) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — MongoDB support in Prisma 7 · 2025-11-19 · Upgrade to Prisma ORM 7

Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

• Does @prisma/adapter-pg's PrismaPg still accept a pre-built pg.Pool instance, or only a PoolConfig it constructs the pool from? Two arms (v6-c, v6-d) independently flagged the constructor as having changed and both declined to say which forms the current release accepts; v6-d dates the change to "roughly 6.6". The battery's schema is not the surface that would answer it. (open since 2026-09-12)
• This draw and v1r-b were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart (7.0.0 / 2025-11-19 here; 6.7.0 / 2025-04-29 there). Prisma was pre-registered as the library expected to replicate tightly, on the reasoning that its version history is unambiguous where langchain's is not. That reasoning is now falsified. (open since 2026-09-01)
• This draw hedged its own answer in a way the scoring rule does not capture: it called 7.0 describable "at headline level only" and volunteered that "for genuinely detailed release-note knowledge, the honest boundary is ~6.16, September 2025". Scored on its stated first-unknown-release it reads 7.0.0; scored on its stated confidence floor it reads 6.16.0. The battery has no rule for a subject that offers two boundaries in one answer. (open since 2026-09-01)
• This draw and v1r-a were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart. Prisma was pre-registered as the library expected to replicate tightly; it did not. (open since 2026-09-01)
• This draw stated 6.7.0 as its boundary while producing a correct, complete, and explicitly disclaimed description of 7.0.0's contents. That is a third mode beyond the two langchain/v1r found: not a correct attribution and not a bare version string, but correct content the subject refuses to attribute. Whether the boundary instrument should score the statement or the production is now an open method question, and it is not answered by either battery. (open since 2026-09-01)
• 6.8.0 (2025-05-15) is unresolved for this draw: it said it could describe "roughly 6.7-6.8", named 6.7 as the newest it could genuinely describe, and put "6.9-and-later" in the version-number-only bucket. The bracket recorded here uses the subject's two explicit statements (6.7.0 describable, 6.9.0 not) and leaves 6.8.0 unclassified rather than guessing. (open since 2026-09-01)
• Both Opus 5 draws in this battery placed query-plan caching at the queryCompiler preview (6.7.0 / 7.0.0) rather than at 7.4.0, and both described the mechanism roughly correctly while dating it wrong. Is that a general shape — a feature whose PUBLIC name arrives in one release and whose CAPABILITY is the completion of work named in an earlier one gets attributed to the earlier one? next.js and better-auth both have candidate surfaces with that structure. Worth a battery designed around it rather than a note. (open since 2026-09-05)
• This draw's self-report about where its content knowledge stops (6.9/6.10) is four releases below where it demonstrably stops (7.0.0, described correctly in the same answer). Every boundary number the Index publishes for every subject comes from the self-report. How often is the self-report an UNDER-estimate of demonstrated knowledge, and does it bias the published boundaries downward? This is the first draw where both readings are available in one transcript and they disagree. It would take a battery that asks for content and for the self-placement about the same releases, deliberately, to answer. (open since 2026-09-05)

Findings, code and citations: data/prisma/ — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: data/prisma/facts.json. This file is generated by tools/build-corrections.mjs; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.

The Stale Priors Index, Unattended Works (https://stalepriors.com/corrections/prisma.md), CC BY 4.0. Retrieved 2026-09-12. Licence: <https://creativecommons.org/licenses/by/4.0/> (SPDX-License-Identifier: CC-BY-4.0). Quoted changelog text belongs to its authors; nothing here grants any right in the libraries described. Terms in full: <https://stalepriors.com/data/LICENSE>.