# Prisma 8 rc.13: the release candidate that ships its own upgrade recipe

> Prisma ORM 8 is a full TypeScript rewrite of the ORM, published so far only as a release candidate, with 8.0.0 final expected in four to eight weeks. The parts worth understanding before you install are what the two installers write into your repository, which databases are genuinely first-class, and how much the minimal core pushes out to extension authors.

**prisma/prisma** — A type-safe ORM for modern TypeScript and Node.js applications.

- Repository: https://github.com/prisma/prisma
- Website: https://www.prisma.io
- Stars: 47,681 · Forks: 2,542
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/prisma-prisma

## Node.js 24 is the floor, and the only recent tags are release candidates

Prerequisites are short and unforgiving: Node.js 24 or newer, plus a package manager, which can be npm, pnpm, or yarn. Everything about versioning is less settled. The three most recent releases are v8.0.0-rc.13 on 2026-09-28, v8.0.0-rc.12 on 2026-09-24, and v8.0.0-rc.11 on 2026-09-13, so three candidates landed in two weeks and a fourth is not far off, and the repository was pushed on 2026-09-29. The stated window for 8.0.0 final is four to eight weeks from now. Until that release, a candidate may include breaking changes, which means your lockfile can move under you without a major version bump telling you so. The project positions this as a feature not being built yet rather than churn, and treats bugs in the candidate as urgent, but the practical effect for a reader is that version numbers are not yet a stability signal. One more detail to settle early: the README header links to github.com/prisma/orm, including the CI badge and the v7 branch link, while the project is published as prisma/prisma, so check which URL you actually cloned before you file anything.

## Prisma 7 lives on its own branch and gets eighteen months from a date that has not happened

Prisma 7 is not deprecated. It remains fully supported, its source lives on the v7 branch rather than on main, and its documentation sits at a separate versioned path, prisma.io/docs/orm/v7, which is how the two lines stay readable. What is easy to misread is the support window. Prisma 7 receives bug fixes and security updates for eighteen months after 8.0.0 final, and 8.0.0 final has not shipped yet. So the clock you care about has not started, and calculating an end of support date from today's date gets the answer wrong by however long the release candidate phase takes. For an existing Prisma 7 application the migration is incremental rather than a big bang, and the repository keeps a reference path in examples/prisma7-adoption/ plus a directory of upgrade instructions. For anyone starting fresh, the instruction is the opposite: new projects should start on 8. The consequence for a reader is that most tutorials and framework guides you find will show 7 patterns, so treat them as v7 documentation unless they say otherwise.

## PostgreSQL and MongoDB are first-class, SQLite is a proof of concept, MySQL is a promise

The supported database list is short enough to read twice. PostgreSQL is the primary target with first-class support. MongoDB is first-class. SQLite is planned next and is a proof of concept today. MySQL follows after SQLite. That ordering is the single most important fact for anyone choosing an ORM, because it inverts the expectation set by earlier versions of the project where MySQL was a mainstream target. The README does not give per-database feature detail in the text; it points at scorecard.md, and the repository also carries a scorecard/ directory, so the authoritative matrix is a document that changes as candidates land. Given rc.11, rc.12, and rc.13 shipped inside two weeks, a row you read today is not a guarantee for the rc you pin next month. In the examples directory you can see the same ordering: examples/prisma-8-demo/, examples/mongo-demo/, examples/mongo-blog-leaderboard/, examples/supabase/, and a proof-of-concept examples/prisma-8-demo-sqlite/, with no MySQL example at all. Consequence: if your production database is MySQL, this release is not a drop-in for you, and the gap is a database, not a configuration.

## The minimal core is a public SPI, and Postgres support is itself an extension

The architectural claim is unusually direct: Prisma 8 has a minimal core, and everything around it, including Postgres support itself, is built on the same public SPI available to any author. That sentence has two consequences. First, integrating a tool, a database, or a library no longer requires working inside the ORM, and the call for extension authors walks through the SPI and the layers an extension can hook into. Second, and less comfortably, the primary target database is not part of the trusted core, so a regression in Postgres behaviour can arrive as a package update to an adapter rather than as a core fix. The extensions already shipping show both the reach and the risk: @prisma/orm-extension-pgvector for vector columns and similarity search, @prisma/orm-extension-postgis for geometry columns and geo queries, @prisma/orm-extension-arktype-json for JSON columns validated by an arktype schema, @cipherstash/prisma-next for searchable encryption and data-level access control, and two marked experimental, @prisma/orm-extension-paradedb for BM25 full-text search indexes and @prisma/orm-extension-supabase for Supabase auth and storage tables with role-bound clients. Put the experimental two on a path you can afford to break, and read the extension notes before depending on any of the six.

## orm init writes four files and promises not to touch your framework, which is also a limit

For a new project, the interactive scaffolder is one command:

```bash
npm create prisma
```

It picks an app template from Next.js, Hono, Nuxt, Astro, NestJS, SvelteKit, TanStack Start, and Elysia, and wires Prisma 8 in with PostgreSQL or MongoDB, ending with a runnable app, a starter contract, and the agent skills already installed. For an existing project, run this from the repo root:

```bash
npx prisma orm init
npx prisma skills sync
```

What orm init actually does is worth reading precisely: it writes prisma.config.ts, scaffolds a starter contract and db.ts under src/prisma/, installs the runtime, and emits the contract. It does not touch your framework or build setup. That sentence is a promise and a warning at once. The CLI will not configure your bundler, your Vite plugin, your Cloudflare Workers setup, or your deployment pipeline, and examples/prisma-8-cloudflare-worker/ exists precisely because that case needs work the installer does not do. One more gap: the word contract appears several times in these steps and the README never defines it, so before you build on the generated files, read ARCHITECTURE.md and gotchas.md rather than guessing from the scaffold output.

## The install writes a prisma-8.md primer and four SKILL.md trees into your repository

Both installers leave generated files behind, and you should know exactly what. There is a top-level prisma-8.md primer at the project root that any agent is meant to read first, and one SKILL.md per workflow is installed into four separate trees: .claude/skills/<skill-name>/SKILL.md for Claude Code, .cursor/skills/<skill-name>/SKILL.md for Cursor, .agents/skills/<skill-name>/SKILL.md described as the universal location for Copilot Agent and other runtimes, and .devin/skills/<skill-name>/SKILL.md for Devin. The good part is provenance: the skills ship inside the Prisma packages your project installs, so they always describe the version in use rather than a version someone forgot to update. The consequence is ownership. Those four directories are regenerated from your lockfile, so they churn on every upgrade, and you have to decide whether they belong in version control, in .gitignore, or in a review policy before the first pull request rather than after. The feedback path deserves the same scrutiny: the prisma-8 skill drafts a structured GitHub issue or hands you a Prisma Discord link, and you can review and confirm before anything is submitted. That confirmation step is the only thing between an agent and your issue tracker.

## The monorepo runs pnpm, turbo, biome and vitest, and none of it is required of your app

The root package.json is a private package named @internal/monorepo at version 8.0.0-rc.13, type module, with packageManager pinned to pnpm@10.27.0. Its scripts are the maintainers' workflow rather than yours: build is turbo run build, format is pnpm biome format --write ., test is turbo run test --continue, and vitest.config.ts sits alongside coverage.config.json, coverage.config.schema.json, and dependency-cruiser.config.mjs for dependency edges. Formatting and linting go through biome and biome-plugins/ rather than a separate linter. None of that is a requirement for a consuming application, and the prerequisites explicitly accept npm, pnpm, or yarn while the getting started path uses npm create prisma, so the mismatch is intentional. What is worth copying is reproducibility: pnpm-lock.yaml and pnpm-workspace.yaml pin the tree, and a bug report is easier to act on if your install matches. Upstream changes are also shaped by tooling, since .husky/, .coderabbit.yml, .tool-versions, rules-footprint.config.schema.json, and the rules-footprint check are all in the tree, and substantive changes are expected to open an issue before implementation begins.

## docker-compose.yaml is one Postgres on host port 5433 with a tmpfs data directory

The compose file is six lines of intent, and reading it as a deployment recipe will mislead you. It defines a single service, postgres on the image postgres:15-alpine, mapping host port 5433 to container port 5432, with POSTGRES_PASSWORD set to the literal string postgres and a tmpfs mount on /var/lib/postgresql/data. Three consequences follow. The port offset means your local Prisma config points at 5433 while a managed Postgres you provision elsewhere is on 5432, so the connection string you develop against is not the one you deploy with. The password is a committed placeholder, which is fine for a throwaway container and wrong for anything else. And a tmpfs data directory means the database contents do not survive a container restart, so this is a test fixture. For a real local database you need a named volume. For per-database and per-framework reference setups, the examples directory is the actual documentation: examples/prisma-8-demo/, examples/mongo-demo/, examples/mongo-blog-leaderboard/, examples/retail-store/, examples/react-router-demo/, examples/supabase/, examples/bundle-size/, examples/multi-extension-monorepo/, examples/paradedb-demo/, examples/prisma-8-postgis-demo/, examples/prisma-8-demo-sqlite/, and examples/prisma7-adoption/.

## Conclusion

Prisma 8 fits a reader starting a new PostgreSQL or MongoDB project on Node.js 24 who wants the agent skills and the contract scaffolding wired in from the first commit, and who can accept that the version number is a release candidate today. It does not fit a MySQL project, because SQLite is still a proof of concept and MySQL follows after it, nor a team that cannot absorb a breaking change between rc builds. Before you commit, check four things: whether 8.0.0 final has shipped, since every release candidate may include breaking changes and the fix is an upgrade recipe applied by the prisma-8 skill; which rows in scorecard.md your chosen database has; whether the four generated SKILL.md directories belong in version control in your project; and which repository URL you clone, because the README header links to github.com/prisma/orm while the project is published as prisma/prisma.

## FAQ

### how to install prisma

You need Node.js 24 or newer and a package manager, npm, pnpm, or yarn. For a new project run npm create prisma, which picks an app template and a database, or run npx prisma orm init from the repo root of an existing project and then npx prisma skills sync.

### how to install prisma in node js

From your repo root, npx prisma orm init writes prisma.config.ts, scaffolds a starter contract and db.ts under src/prisma/, installs the runtime, and emits the contract, and it does not touch your framework or build setup. Follow it with npx prisma skills sync, and note that the floor is Node.js 24 or newer.

### how to install prisma in next js

Next.js is one of the app templates the interactive scaffolder offers. Running npm create prisma lets you select Next.js along with PostgreSQL or MongoDB, and you finish with a runnable app, a starter contract, and the agent skills already installed.

### how to install prisma in nestjs

NestJS is one of the templates the interactive scaffolder offers, alongside Next.js, Hono, Nuxt, Astro, SvelteKit, TanStack Start, and Elysia. Run npm create prisma, choose NestJS and PostgreSQL or MongoDB, and the scaffolder wires Prisma 8 into the generated app.

### how to use prisma

The intended path is to describe what you want and let an agent drive it: both installers leave a prisma-8.md primer at the project root and install one SKILL.md per workflow into .claude/, .cursor/, .agents/, and .devin/ skill directories. Those skills ship inside the installed packages, so they describe the version you actually have, and your editor's assistant loads the matching one when your prompt fits.

### how to install prisma 6

The README does not cover Prisma 6; the versions it discusses are Prisma 7 and Prisma 8. Prisma 7 remains fully supported on the v7 branch with its own docs at prisma.io/docs/orm/v7, and keeps bug fixes and security updates for eighteen months after 8.0.0 final ships.

## Sources

- [Official documentation](https://www.prisma.io)
- [Official README](https://github.com/prisma/prisma#readme)
- [Project repository](https://github.com/prisma/prisma)
- [Release notes](https://github.com/prisma/prisma/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prisma-prisma