Prisma ORM
Pathrule3 Rules • 1 Memory • 1 Skill
Prisma 7 broke the shape of the code every assistant memorised. The generator is now `prisma-client` with a required `output`, so `PrismaClient` is imported from your generated directory rather than from the package. Every connection goes through a driver adapter, the middleware API is gone in favour of client extensions, and automatic seeding on migrate was removed. This bundle encodes the current API plus the two things that hurt in production regardless of version: one client per process, and queries that select what they need.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
prisma-v7-upgrade
prisma/
Use the prisma-client generator with an explicit output
Migration workflow and what Prisma 7 removed
src/
db/
One client per process, constructed with a driver adapter
Select explicitly, batch relations, and keep transactions short
Rules
3Use the prisma-client generator with an explicit output/prismahighstrictThe schema declares `provider = "prisma-client"` and an `output` directory, and code imports the client from there, not from the package root.
| 1 | Prisma 7 made the Rust-free client the default and changed how it is generated. The old block simply does not work, and the import path changed with it. |
| 2 | |
| 3 | - The generator block is `generator client { provider = "prisma-client" output = "./generated/prisma" }`. `output` is required; `prisma-client-js` and `engineType` are gone. |
| 4 | - Import from the generated location (`import { PrismaClient } from "./generated/prisma/client"`), not from `@prisma/client`. Fix the import everywhere in the same change, because the old path resolves to something that will not run. |
| 5 | - Decide whether the generated directory is committed or generated in CI, then be consistent: if it is gitignored, `prisma generate` must run in every build and before typecheck, since types now come from that folder. |
| 6 | - Put configuration (schema path, migrations, seed command) in `prisma.config.ts` at the project root rather than in `package.json`, which is where Prisma 7 expects it. |
| 7 | - Seeding is explicit now: run `prisma db seed` yourself, because migrations no longer trigger it. |
One client per process, constructed with a driver adapter/src/dbhighstrictExport a single PrismaClient built on a driver adapter, cache it across hot reloads, and never construct one per request.
| 1 | In Prisma 7 every database connection goes through a driver adapter, and the client owns a connection pool. Creating one per request or per module reload is how a small app exhausts a database. |
| 2 | |
| 3 | - Build the adapter for your database (`new PrismaPg({ connectionString })` for Postgres, the matching adapter for MySQL, SQLite, or a serverless driver) and pass it in: `new PrismaClient({ adapter })`. |
| 4 | - Export one instance from a single module and import that everywhere. In development, cache it on `globalThis` so hot reload does not open a new pool on every file save. |
| 5 | - In serverless or edge runtimes, keep the client in module scope so it is reused across invocations of the same instance, and put a pooler (PgBouncer, a platform pooler, or a serverless driver adapter) between the function and the database. Concurrency there is the number of instances, not the number of requests. |
| 6 | - Do not call `$connect()` eagerly or `$disconnect()` per request; the client connects lazily and disconnecting per request defeats pooling. Disconnect only in scripts and tests that end. |
| 7 | - Extend behaviour with client extensions (`$extends`) for logging, soft delete, computed fields, or row-level filters. The `$use` middleware API was removed. |
Select explicitly, batch relations, and keep transactions short/src/dbhighstrictEvery query names the fields it needs, related data is loaded with include or a batched query, and interactive transactions stay tiny.
| 1 | Prisma makes over-fetching easy to write and hard to see: a model query returns every column, and a relation accessed in a loop is a query per row. |
| 2 | |
| 3 | - Use `select` (or a narrow `include`) on anything that leaves a request handler. A default query returns all scalar fields, which is how a token or a hashed password ends up in an API response. |
| 4 | - Load relations in the query with `include` or `select`, not by iterating results and querying per item. When you truly need per-item work, fetch the set in one `findMany({ where: { id: { in: ids } } })` and key it in memory. |
| 5 | - Wrap multi-write invariants in a transaction: `$transaction([...])` for independent writes, the interactive form only when a later write depends on an earlier read. Keep interactive transactions free of network calls and set a timeout; a long one holds locks and blocks other writers. |
| 6 | - Paginate with cursor pagination on a stable indexed column for large or infinite lists; `skip` grows more expensive as the offset grows. |
| 7 | - Only use `$queryRaw` with tagged-template parameters. `$queryRawUnsafe` with interpolated input is SQL injection, and `$executeRaw` bypasses every extension you rely on. |
Memories
1Migration workflow and what Prisma 7 removed/prismamigrate dev locally, migrate deploy in CI, never edit an applied migration, and remember the CLI flags and middleware that no longer exist.
| 1 | The migration model is unchanged, but several conveniences were removed in 7, and code or scripts that relied on them fail quietly. |
| 2 | |
| 3 | - Locally, change the schema and run `prisma migrate dev` to generate and apply a migration. In CI and production, run `prisma migrate deploy`, which only applies pending files and never generates or resets. |
| 4 | - `prisma db push` is for prototyping against a scratch database. It does not create migration files, so never run it against an environment whose history matters. |
| 5 | - Never edit a migration that has been applied anywhere shared. Add a new one, even for a typo. |
| 6 | - Removed in 7 and worth knowing before you write a script: the `$use` middleware API (use `$extends`), the metrics preview feature, the `--skip-generate` and `--skip-seed` CLI flags, `--schema`/`--url` on `prisma db execute`, and automatic seeding as part of migrate. |
| 7 | - Write destructive changes as multi-step: add the new column, deploy code that writes both, backfill, switch reads, then drop. A single migration that renames a column is a deploy-time outage. |
| 8 | |
| 9 | See /src/db for the client and query rules, and the postgres-schema pattern for index and constraint design underneath Prisma. |
Skills
1prisma-v7-upgrade/rootStep-by-step upgrade from Prisma 6 to 7, in the order that keeps the build green.
| 1 | --- |
| 2 | name: prisma-v7-upgrade |
| 3 | description: Ordered procedure to move a codebase from Prisma 6 to Prisma 7: generator block, generated client import, driver adapters, middleware to extensions, and the removed CLI flags. Use when upgrading or when a Prisma 6 shape appears in a Prisma 7 project. |
| 4 | --- |
| 5 | |
| 6 | # Prisma 6 to 7 upgrade |
| 7 | |
| 8 | Run in order. Each step leaves the repo buildable. |
| 9 | |
| 10 | 1. **Pin and read.** Upgrade `prisma` and `@prisma/client` together to the same 7.x version. Mismatched versions produce confusing type errors. |
| 11 | 2. **Switch the generator.** In `schema.prisma`, replace the client generator with: |
| 12 | `generator client { provider = "prisma-client" output = "./generated/prisma" }` |
| 13 | Remove `engineType`. Decide now whether `output` is committed or gitignored. |
| 14 | 3. **Regenerate.** Run `prisma generate` and confirm the directory appears where `output` points. |
| 15 | 4. **Fix imports.** Replace every `from "@prisma/client"` with the generated path (`./generated/prisma/client`, adjusted per file or via a path alias). Include types (`Prisma`, model types, enums), not just `PrismaClient`. |
| 16 | 5. **Add the driver adapter.** Install the adapter for your database, construct it from the connection string, and pass it to the client: `new PrismaClient({ adapter })`. Do this in the single module that exports the client. |
| 17 | 6. **Replace middleware.** Rewrite every `prisma.$use(...)` as a `$extends` client extension (query extension for interception, result extension for computed fields). There is no compatibility shim. |
| 18 | 7. **Move config.** Create `prisma.config.ts` for schema path, migrations, and the seed command, and delete the `prisma` block from `package.json`. |
| 19 | 8. **Fix scripts and CI.** Remove `--skip-generate` and `--skip-seed`, add an explicit `prisma db seed` step where seeding was implicit, and drop `--schema`/`--url` from any `prisma db execute` call. |
| 20 | 9. **Verify.** Typecheck, run the test suite against a real database, and check that `prisma migrate deploy` is still the production command. |
| 21 | |
| 22 | ## Done when |
| 23 | - [ ] No import from `@prisma/client` remains. |
| 24 | - [ ] The client is constructed once, with an adapter. |
| 25 | - [ ] No `$use` call remains anywhere. |
| 26 | - [ ] CI generates the client before typecheck and seeds explicitly. |
Why this pattern
AI agents still generate the Prisma 6 shape: the prisma-client-js generator, an import from the package root, no driver adapter, and a new PrismaClient per request or per hot reload.
Built for TypeScript teams running Prisma 7 against Postgres, MySQL, or SQLite.
Keeps your assistant from:
- Writing a prisma-client-js generator block that Prisma 7 no longer accepts
- Importing PrismaClient from @prisma/client instead of the generated output directory
- Instantiating a client per request and exhausting the database connection pool
- Using the removed middleware API instead of client extensions
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-08-24