# prisma correction pack · for projects on prisma@7 / @prisma/client@7
<!--
     Stale Priors Index · Unattended Works · https://github.com/SamAndrzejewski

     GENERATED FILE — DO NOT EDIT BY HAND. Your edit will be destroyed by the next build.
     Rebuild:  node tools/build-corrections.mjs
     Sources:  data/prisma/facts.json  (the corrections, each verified against a primary source)
               data/prisma/*.json      (the evidence: reproduced model failures)

     Latest prisma: 7.10.0 · verified 2026-09-06
     Coverage: Claude Fable 5, Claude Fable 5.1, Claude Haiku 4.5, Claude Opus 5, Claude Sonnet 5 — prisma/v1 (2026-08-31), prisma/v1r-a (2026-09-01), prisma/v1r-b (2026-09-01), prisma/v2-a (2026-09-05), prisma/v2-b (2026-09-05), prisma/v2-c (2026-09-05), prisma/v2-d (2026-09-05), prisma/v4-a (2026-09-06), prisma/v4-b (2026-09-06), prisma/v4-c (2026-09-06), prisma/v4-d (2026-09-06), prisma/v4-e (2026-09-06), prisma/v4-f (2026-09-06), prisma/v5-a (2026-09-06), prisma/v5-b (2026-09-06), prisma/v5-c (2026-09-06), prisma/v5-d (2026-09-06), prisma/v5-e (2026-09-06), prisma/v5-f (2026-09-06), prisma/v5-g (2026-09-06)

     Paste into CLAUDE.md / AGENTS.md / .cursorrules if your project uses prisma@7 / @prisma/client@7.
     Do NOT use if you are pinned to prisma@6 or earlier, which is still maintained and is still the supported line for MongoDB.
-->

## What we actually measured

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

| Model | Stated cutoff | prisma version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Sonnet 5 | 2026-01 | 6.0.0 · 2024-11-28 | ~14 months |
| Claude Opus 5 | 2026-05 | 6.7.0 · 2025-04-29 | ~13 months |
| Claude Fable 5 | 2026-01 | 6.7.0 · 2025-04-29 | ~8 months |
| Claude Fable 5.1 | 2026-06 | 7.0.0 · 2025-11-19 | ~7 months |

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-06). Separately from the corrections below, 3 of 22 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.

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

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

```bash
# 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### `engineType`

**Removed in prisma 7.0.0** (2025-11-19)

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.

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

*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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### generator client { output }

**New requirement in prisma 7.0.0** (2025-11-19)

`output` is required in the generator block. Prisma 7 does not generate the client into `node_modules` at all, so a generator block without an output path fails rather than defaulting.

*The stale belief:* That `prisma generate` writes into `node_modules/.prisma/client` and `output` is an optional advanced setting.

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

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

> The vendor recommends generating inside your own source tree (for example `src/`) so the output is handled by your existing tooling like any other code.

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

Source: [Upgrade to Prisma ORM 7 — Schema changes](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7) · [Prisma 7.0.0 release notes — Generated Client and types move out of node_modules](https://github.com/prisma/prisma/releases/tag/7.0.0) · 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: the generated client is now a file in your repository.

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

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

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

Source: [Upgrade to Prisma ORM 7 — Schema changes](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

#### new PrismaClient()

**Removed in prisma 7.0.0** (2025-11-19)

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; 7.1.0 added a dedicated error message for the no-argument case, so the failure is a runtime throw at construction, not a type error you will notice in review.

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

```ts
// 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 })
```

> The adapter package depends on the database: `@prisma/adapter-pg` for Postgres, `@prisma/adapter-better-sqlite3` for SQLite, `@prisma/adapter-mariadb` for MySQL/MariaDB.

*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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Upgrade to Prisma ORM 7 — Driver adapters](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

#### package.json prisma key

**Removed in prisma 7.0.0** (2025-11-19)

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.

```jsonc
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### prisma generate --no-engine

**Removed in prisma 7.0.0** (2025-11-19)

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

```bash
# 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### `prisma.config.ts`

**New requirement in prisma 7.0.0** (2025-11-19)

`prisma.config.ts` is required for any project that runs introspection or migrations. The datasource URL lives there, not in `schema.prisma`. The file itself was introduced as opt-in in 6.18.0 and became mandatory in 7.0.0.

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

```ts
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') },
})
```

*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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Prisma 6.18.0 release notes — prisma init now creates a prisma.config.ts automatically](https://github.com/prisma/prisma/releases/tag/6.18.0) · 2025-10-22

#### datasource db { url }

**Removed in prisma 7.0.0** (2025-11-19)

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

```prisma
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### prisma.config.ts engine key

**Removed in prisma 7.0.0** (2025-11-19)

The `engine: 'js' | 'classic'` and `adapter` keys in `prisma.config.ts` were removed in 7.0.0. They existed only in the 6.18.0-6.19.x window, where the config file was opt-in and `engine: "classic"` selected the Rust engine that 7.0.0 deleted.

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

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

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

> This key is a dating fingerprint: code containing it was learned from a release published between 2025-10-22 and 2025-11-19, a 28-day window.

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

Source: [Prisma 7.0.0 release notes — Schema and config file updates](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Prisma 6.18.0 release notes — Support for defining your datasource in prisma.config.ts](https://github.com/prisma/prisma/releases/tag/6.18.0) · 2025-10-22

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

**Added in prisma 7.4.0** (2026-02-11)

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.` at 7.4.0 and at 7.10.0. 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.

*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`.

```prisma
// 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. `@@index([email], include: [name])` and `@@unique([email], nullsNotDistinct: true)` are each rejected by `prisma validate` with `No such argument.` at prisma@7.4.0 and at prisma@7.10.0. Same run, same file, the only difference being the argument name: `where:` validates and `include:`/`nullsNotDistinct:` do not, 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.

*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](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz) · [Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support](https://github.com/prisma/prisma/releases/tag/7.4.0) · 2026-02-11

#### `@prisma/client-runtime-utils`

**New requirement in prisma 7.0.0** (2025-11-19)

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.

```bash
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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### /wasm export path

**Renamed in prisma 7.0.0** (2025-11-19)

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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [@prisma/client 7.0.0, shipped package — edge.d.ts](https://registry.npmjs.org/@prisma/client/-/client-7.0.0.tgz)

#### `accelerateUrl`

**Added in prisma 7.0.0** (2025-11-19)

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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Upgrade to Prisma ORM 7 — Prisma Accelerate](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7) · [prisma 7.0.0, shipped package — generated PrismaClientOptions](https://registry.npmjs.org/prisma/-/prisma-7.0.0.tgz)

#### ESM and toolchain minimums

**New requirement in prisma 7.0.0** (2025-11-19)

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

```jsonc
{
  "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](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

#### metrics preview feature

**Removed in prisma 7.0.0** (2025-11-19)

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.

```prisma
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### new PrismaClient({ datasources })

**Removed in prisma 7.0.0** (2025-11-19)

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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### new PrismaClient({ datasourceUrl })

**Removed in prisma 7.0.0** (2025-11-19)

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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### prisma introspect

**Removed in prisma 7.0.0** (2025-11-19)

The deprecated `prisma introspect` command was removed in 7.0.0 — `prisma db pull` is the only spelling. `db pull` also lost its undocumented `--url` flag and its `--local-d1` flag.

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

```bash
# Stale
npx prisma introspect

# Current
npx prisma db pull
```

*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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

### 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.2.0** (2025-12-17)

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. Its first stable release is 7.2.0. Before it existed 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.

```ts
// 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, released with 7.2.0
// 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 — all three read off the registry and the release notes — and does not put a configuration snippet in a subject’s mouth that it has not executed. The registry `time` map gives 7.2.0 on 2025-12-17 as the first stable version; the only earlier publishes are a `0.0.1` placeholder on 2025-12-04 and `7.2.0-dev.*` pre-releases.

*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 ORM 7.2.0 release notes — SQL Commenter plugin](https://github.com/prisma/prisma/releases/tag/7.2.0) · 2025-12-17 · [npm registry metadata for @prisma/sqlcommenter-query-insights — first stable release 7.2.0, published 2025-12-17](https://registry.npmjs.org/@prisma/sqlcommenter-query-insights) · 2025-12-17

#### `queryPlanCacheMaxSize`

**Added in prisma 7.8.0** (2026-04-22)

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. It is an ordinary documented optional property of the client options type — not an internal, and not an environment variable.

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

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

*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](https://github.com/prisma/prisma/releases/tag/7.8.0) · 2026-04-22 · [@prisma/client 7.8.0, shipped package — runtime/client.d.ts](https://registry.npmjs.org/@prisma/client)

#### prisma bootstrap

**Added in prisma 7.7.0** (2026-04-07)

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

```shell
# 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](https://github.com/prisma/prisma/releases/tag/7.7.0) · 2026-04-07 · [prisma 7.7.0, shipped package — output of `prisma --help`](https://registry.npmjs.org/prisma)

#### new PrismaPg(connectionString)

**Added in prisma 7.6.0** (2026-03-27)

`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 }`.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.6.0) · 2026-03-27 · [@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts](https://registry.npmjs.org/@prisma/adapter-pg)

#### prisma postgres link

**Added in prisma 7.6.0** (2026-03-27)

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.

```shell
# 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](https://github.com/prisma/prisma/releases/tag/7.6.0) · 2026-03-27 · [prisma 7.6.0 and 7.10.0, shipped package — output of `prisma postgres --help`](https://registry.npmjs.org/prisma)

#### `statementNameGenerator`

**Added in prisma 7.6.0** (2026-03-27)

`@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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.6.0) · 2026-03-27 · [@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts](https://registry.npmjs.org/@prisma/adapter-pg)

#### `tx.$transaction()`

**Added in prisma 7.5.0** (2026-03-11)

`$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.

```ts
// 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](https://github.com/prisma/prisma/releases/tag/7.5.0) · 2026-03-11 · [@prisma/client 7.5.0, shipped package — runtime/client.d.ts](https://registry.npmjs.org/@prisma/client)

#### prisma db push --url

**Added in prisma 7.2.0** (2025-12-17)

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`, `prisma db pull` and `prisma migrate dev`, described in the help table as "Override the datasource URL from the Prisma config file". Before 7.2.0 these commands 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.

```bash
# 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 rather than the release note alone. `prisma db push --help` lists no `--url` at 5.22.0, 6.19.0, 7.0.0 or 7.1.0, and lists it at 7.2.0; `migrate dev` and `db pull` behave the same way across those versions. `db pull` is the one of the three with a pre-history — `prisma introspect --url` existed in the 2.x era — but the flag is absent from `db pull --help` at 5.22.0, 6.19.0, 7.0.0 and 7.1.0, so for every version this Index covers 7.2.0 is where it appears. 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`.

*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](https://github.com/prisma/prisma/releases/tag/7.2.0) · 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](https://registry.npmjs.org/prisma/-/prisma-7.2.0.tgz) · 2025-12-17

#### automatic .env loading

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

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.

```ts
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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

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

**Added in prisma 7.4.0** (2026-02-11)

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

```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](https://github.com/prisma/prisma/releases/tag/7.4.0) · 2026-02-11 · [prisma 7.4.0, shipped package — build/prisma_schema_build_bg.wasm](https://registry.npmjs.org/prisma/-/prisma-7.4.0.tgz) · [prisma 7.10.0, shipped package — `prisma validate` on the correct_code schema above](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz)

#### `compilerBuild`

**Added in prisma 7.3.0** (2026-01-21)

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.

```prisma
// 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](https://github.com/prisma/prisma/releases/tag/7.3.0) · 2026-01-21 · [prisma@7.3.0 shipped CLI — `compilerBuild` present in build/index.js; absent from prisma@7.2.0](https://registry.npmjs.org/prisma/-/prisma-7.3.0.tgz) · 2026-01-21

#### postinstall prisma generate

**Removed in prisma 7.0.0** (2025-11-19)

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.

```bash
# 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### enum member @map

**Behaviour changed in prisma 7.3.0** (2026-01-21)

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.

```ts
// 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)](https://github.com/prisma/prisma/releases/tag/7.3.0) · 2026-01-21 · [prisma 7.10.0 — client generated from a schema with @map on every enum member](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz) · [prisma 7.2.0 — the same schema, the last release before the revert](https://registry.npmjs.org/prisma/-/prisma-7.2.0.tgz) · [Prisma 7.0.0 release notes — Mapped enums, the change that was later reverted](https://github.com/prisma/prisma/releases/tag/7.0.0) · 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.

```ts
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](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

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

`prisma-client` is the default generator provider in Prisma 7 — the Rust-free ESM client. `prisma-client-js` still works but is stated to be removed in a future release, and using it together with the now-required `output` needs an extra package, `@prisma/client-runtime-utils`.

*The stale belief:* That `prisma-client-js` is the only generator provider, which was true until the `prisma-client` preview landed in 6.16.0.

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

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

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

Source: [Upgrade to Prisma ORM 7 — Schema changes](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7) · [Prisma 7.0.0 release notes — ESM Prisma Client as the default](https://github.com/prisma/prisma/releases/tag/7.0.0) · 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](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Upgrade to Prisma ORM 7](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

## Not corrections — recorded for honesty

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

- 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)*
- Does the `prisma-client` generator accept a `runtime` key with values such as "vercel-edge" and "workerd", as the serverless answer claims? *(open since 2026-08-31)*

---

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