# prisma — corrections from the Stale Priors Index

<!--
     Stale Priors Index · Unattended Works · https://stalepriors.com/rules/prisma.md

     The Stale Priors Index, Unattended Works (https://stalepriors.com/rules/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
     Quotations from third-party changelogs remain their authors'; nothing here grants any
     right in the libraries described. Full map: https://stalepriors.com/data/LICENSE

     Changed since the 2026-09-12 sweep: none of the 39 entries below.

     GENERATED FILE — DO NOT EDIT BY HAND. Your edit will be destroyed by the next build.
     Rebuild:  node tools/build-rules.mjs
     Source:   data/prisma/facts.json
-->

For projects on **prisma@7 / @prisma/client@7**. 39 corrections, 38 of them dated to the release that changed the behaviour; every entry links the primary source it was verified against. Latest prisma: 7.10.0, verified 2026-09-12. Do **not** use this if you are pinned to prisma@6 or earlier, which is still maintained and is still the supported line for MongoDB.

**This is the statements only** — no reproduced model failures, no code, no evidence. The full pack has all three: https://stalepriors.com/corrections/prisma.md

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

**What was measured, and what this file is not.** The benchmark run on this library measured prisma × Claude Sonnet 5, tasks drawn 2026-09-10, cells recorded 2026-09-12: the **full prisma correction pack**, 94,296 characters of it — terminal pass rate 22/22 without it against 22/22 with it, first attempt 9/22 against 20/22, and a cost that takes 30.5 tasks in one session to repay, counted in this run's mix, where 12 of the bare arm's 34 cells were null tasks. **This file is a subset of that pack and no measurement covers it.** Every cell: https://stalepriors.com/benchmark

The corrections below are 36,236 characters. Read that as a cost: a rules file is added to requests, so it is a decision to make rather than a default to accept.

## Breaks the build, or throws at runtime

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

*Verified against:* [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)

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

*Verified against:* [Prisma 7.0.0 release notes — Miscellaneous](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — For Prisma Accelerate users](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Schema changes](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Driver Adapter naming updates](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Removed Client Engines](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Upgrade to Prisma ORM 7 — ESM support / Prerequisites](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

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

*Verified against:* [Upgrade to Prisma ORM 7 — Schema changes](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.

*Verified against:* [Prisma 7.0.0 release notes — Deprecated metrics feature has been removed](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Prisma Client changes](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Prisma Client changes](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Prisma Client changes](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Removed support for prisma keyword in package.json](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Removal of prisma generate flags](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Miscellaneous](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Removal of prisma migrate flags](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Prisma 7.0.0 release notes — Schema and config file updates](https://github.com/prisma/prisma/releases/tag/7.0.0)

### `prisma.config.ts engine key`

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

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.

*Verified against:* [Prisma 7.0.0 release notes — Schema and config file updates](https://github.com/prisma/prisma/releases/tag/7.0.0)

### `generator client { runtime }`

**Renamed in prisma 6.15.0** (2025-08-27).

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.

*Verified against:* [Prisma ORM 6.15.0 release notes — `prisma-client`: runtime improvements and schema flexibility](https://github.com/prisma/prisma/releases/tag/6.15.0)

### `generator client { output }`

**New requirement in prisma 6.6.0** (2025-04-08).

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.

*Verified against:* [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"](https://registry.npmjs.org/prisma/-/prisma-6.6.0.tgz)

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

**No release changed this.** Stable across every release measured.

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

*Verified against:* [prisma 7.10.0, shipped package — `prisma validate` on the stale_code schema above](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz)

## Runs, but is silently wrong

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

*Verified against:* [Prisma 7.8.0 release notes — Prisma Client features](https://github.com/prisma/prisma/releases/tag/7.8.0)

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

*Verified against:* [Prisma 7.7.0 release notes — `prisma bootstrap` command](https://github.com/prisma/prisma/releases/tag/7.7.0)

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

*Verified against:* [Prisma 7.6.0 release notes — Driver Adapters](https://github.com/prisma/prisma/releases/tag/7.6.0)

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

*Verified against:* [Prisma 7.6.0 release notes — CLI](https://github.com/prisma/prisma/releases/tag/7.6.0)

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

*Verified against:* [Prisma 7.6.0 release notes — Driver Adapters](https://github.com/prisma/prisma/releases/tag/7.6.0)

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

*Verified against:* [Prisma 7.5.0 release notes — Features](https://github.com/prisma/prisma/releases/tag/7.5.0)

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

*Verified against:* [Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support](https://github.com/prisma/prisma/releases/tag/7.4.0)

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

*Verified against:* [Prisma ORM 7.3.0 release notes — new `compilerBuild` generator option](https://github.com/prisma/prisma/releases/tag/7.3.0)

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

*Verified against:* [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)

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

*Verified against:* [Prisma ORM 7.2.0 release notes](https://github.com/prisma/prisma/releases/tag/7.2.0)

### `@prisma/sqlcommenter-query-insights`

**Added in prisma 7.1.0** (2025-12-04).

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.

*Verified against:* [@prisma/sqlcommenter-query-insights 0.0.1, shipped package — dist/index.d.ts, installed and read 2026-09-07](https://registry.npmjs.org/@prisma/sqlcommenter-query-insights/-/sqlcommenter-query-insights-0.0.1.tgz)

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

*Verified against:* [Prisma 7.0.0 release notes — Explicit loading of environment variables](https://github.com/prisma/prisma/releases/tag/7.0.0)

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

*Verified against:* [Upgrade to Prisma ORM 7 — Driver adapters](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

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

*Verified against:* [Prisma 7.0.0 release notes — Removal of implicit Prisma commands](https://github.com/prisma/prisma/releases/tag/7.0.0)

## Deprecated, or a better API now exists

### `generator client { engineType }`

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

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.

*Verified against:* [Prisma 6.16.0 release notes — Rust-free ORM and driver adapters are Generally Available](https://github.com/prisma/prisma/releases/tag/6.16.0)

### `provider = "prisma-client-js"`

**Deprecated in prisma 7.0.0** (2025-11-19).

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.

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

### `previewFeatures = ["driverAdapters"]`

**Added in prisma 6.16.0** (2025-09-10).

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.

*Verified against:* [Prisma 6.16.0 release notes — Rust-free ORM generally available](https://github.com/prisma/prisma/releases/tag/6.16.0)

## Wrong facts about the library

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

*Verified against:* [Prisma 7.0.0 release notes — MongoDB support in Prisma 7](https://github.com/prisma/prisma/releases/tag/7.0.0)

---

*The Stale Priors Index, Unattended Works (https://stalepriors.com/rules/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>.*