Prisma Next: what the TypeScript rewrite actually ships, and what it does not

What Prisma Next is, and who the repository is written for

Prisma Next is a TypeScript rewrite of Prisma ORM. The README describes it as extensible, composable and AI-agent friendly by default, and the repository keeps the older line alive separately: Prisma ORM 7 lives on the `v7` branch, and the `prisma` and `@prisma/*` packages on npm continue to be published from there. That split matters more than any feature list. If you are already running Prisma ORM 7, this repository is not the upgrade path you are on. It is a parallel line with a different core.

The audience the README addresses is narrow and explicit. You need Node.js 24 or newer and a package manager, one of npm, pnpm or yarn. The primary database target is PostgreSQL, which the README says reaches general availability at Prisma 8. MongoDB is early access and described as proof that the framework works beyond SQL. SQLite is called a proof of concept today. MySQL is not available and the README points to the roadmap for what must happen before the 8.0.0-rc.1 release.

So the honest framing is this: Prisma Next is aimed at engineers who want to try a rewritten ORM on Postgres, and at extension authors who want to plug a database, a tool or a library into it. It is not aimed at teams that need a boring, fully supported ORM across several engines today.

The minimal core and the SPI that replaces built-in database support

The architectural claim in the README is that Prisma Next has a minimal core, and that everything around it, including Postgres support itself, is built on the same public SPI available to any author. That is a real design decision with visible consequences. Postgres is not privileged code inside the core. It is an extension like the ones third parties write.

The extensions the README lists show what the SPI is expected to carry. `@internal/extension-pgvector` adds vector columns and similarity operators for semantic search. `@internal/extension-paradedb` adds typed BM25 indexes with multiple tokenizers for full-text search. `@internal/extension-postgis` adds geospatial types and queries. `@cipherstash/prisma-next` is listed as a third-party extension providing searchable encryption and data-level access control. Those are four different kinds of concern (vectors, full-text ranking, geometry, encryption) all landing through the same interface, which is the strongest evidence in the README that the SPI is not just a plugin hook for logging.

The trade-off is the usual one for extension architectures. You get a smaller surface to reason about and a documented path to integrate anything, and you pay for it in coordination: the capabilities you used to get by upgrading the ORM now depend on which extensions are installed and how they are wired. The README does not document how extension versions are pinned or what happens when two extensions target the same query layer. `skills-lock.json` tracks skill versions, not extension versions.

How the agent skills are installed and where they live on disk

The part of Prisma Next that is genuinely unusual is the agent integration, and it is concrete enough to check. Both installers leave a top-level `prisma-next.md` primer at the project root for any agent to read first. The `init` command additionally materialises one `SKILL.md` per workflow in two locations so different agent runtimes find them at their expected paths: `.claude/skills/<skill-name>/SKILL.md` for Claude Code, and `.agents/skills/<skill-name>/SKILL.md` as the universal location for Cursor, Copilot Agent and other runtimes. A `skills-lock.json` at the project root tracks which skill versions are installed.

The README gives one worked example of the intended loop. A prompt like "Add a `posts` model with a relation to `users`, then write a query that loads each user's three most recent posts" causes the agent to load the `prisma-8` skill, open its contract and queries references, and drive the change end to end. Whether that loop holds outside the README's example is something you would have to observe in your own editor. The repository layout does support the claim that skills are first-class: there are `skills/`, `skills-contrib/` and `AGENTS.md` entries at the top level alongside `CLAUDE.md`.

There is a second, smaller design choice worth noting. The feedback flow is routed through the same skill: asking the agent about a bug or a missing feature drafts a structured GitHub issue or hands over a Prisma Discord link, and the README says you review and confirm before anything is submitted. That is a reasonable default, but it also means the primary documented path for reporting a problem runs through an AI agent rather than a plain issue form.

Installing Prisma Next and running the first real change

There are two entry points, and they do different amounts of work. The scaffolder is interactive and picks a JavaScript framework (the README names Next.js, Vite and Hono among others) and wires in your chosen database, PostgreSQL or MongoDB. Run it from an empty directory:

npm create prisma@next

You finish with a runnable app, a starter contract, and the agent skills already registered. If you want to see the generated contract before committing to a framework, this is the fastest way to get one.

The second path is for an existing repository and is the one to use if you already have a build setup you do not want disturbed. Run it from your repo root:

npx @prisma/cli@next orm init

The README states that `prisma orm init` writes `prisma.config.ts`, scaffolds a starter contract and `db.ts` under `src/prisma/`, installs the runtime, emits the contract, and registers the agent skills. It also states that it does not touch your framework or build setup. That last claim is the one to verify in your own checkout, because it is the difference between a five-minute trial and a day of untangling.

If you want a local Postgres to point at, the repository ships one in `docker-compose.yaml`. Note the host port:

services:
  postgres:
    image: postgres:15-alpine
    ports:
      - "5433:5432"
    environment:
      POSTGRES_PASSWORD: postgres

The container listens on host port 5433, not the default 5432, and the password is `postgres`. The compose file mounts the data directory as tmpfs, so the database contents do not survive a container restart. That is fine for a first run and wrong for anything you care about.

Once the contract exists, the first real change is the one from the README: describe the model and query you want to your agent and let the `prisma-8` skill drive it. If you would rather not use an agent, the README does not document a hand-written equivalent workflow, which is itself a gap.

Early access, evolving APIs, and the database matrix as a hard limit

The README is unusually direct about the central limitation: Prisma Next is currently in early access, APIs will still evolve as feedback shapes them, and the team does not recommend it for production workloads yet. That is not a hedge buried in a footnote. It is the second paragraph of the document. Treat it as the governing constraint on everything else here.

The database matrix is the second limit and it is harder than the first. PostgreSQL is the primary target and the only engine at general availability in Prisma 8. MongoDB is early access. SQLite is a proof of concept. MySQL is absent, with the README pointing to the roadmap for what must happen before 8.0.0-rc.1. If your production database is MySQL, this project is not a candidate regardless of how the TypeScript API looks.

The release history reinforces the same point. The most recent releases listed are `v8.0.0-rc.8` on 2026-08-26, `v8.0.0-rc.7` on 2026-08-25 and `v8.0.0-rc.6` on 2026-08-25. Three release candidates inside roughly a day and a half. That cadence is normal for a project stabilising an API, and it is also a signal that pinning to a specific rc and reading its changelog before upgrading is the only sane approach. The monorepo `package.json` reports version `8.0.0-rc.11`, so the workspace itself has moved past the newest published rc listed here.

One more thing the README does not settle: it does not document rollback, and it does not document what happens to a generated contract when you downgrade to an earlier rc. If you generate a contract on rc.8 and step back to rc.6, the outcome is not described anywhere in the README.

Prisma Next against Prisma ORM 7 on the v7 branch

The obvious alternative is the project's own predecessor. Prisma ORM 7 lives on the `v7` branch of this same repository, and the README states that the `prisma` and `@prisma/*` packages on npm continue to be published from there. The difference in approach is not cosmetic. Prisma ORM 7 is the established line with the database coverage and API stability that implies. Prisma Next is a TypeScript rewrite whose core is deliberately minimal, whose Postgres support is itself an extension, and whose API is explicitly still moving.

If you are starting a project today that needs to ship, the v7 line is the one the README itself directs you toward by keeping it as a separate branch with ongoing npm publishing. Choosing Prisma Next means accepting the early access caveat, the Postgres-only general availability, and an extension architecture whose versioning story is not documented. What you get in exchange is the SPI, which is a real offer to anyone who has wanted to integrate a database or a library with Prisma and found no supported way in.

There is a third path worth naming: not using an ORM. The README gives no basis for judging whether that is better for your workload, and this article will not pretend otherwise. The relevant comparison here is between the two lines in this repository, and the README picks a side for production by keeping v7 alive.

Licence, upgrade cost, and what maintenance looks like from the outside

The licence is Apache 2.0, stated in the README and present as a `LICENSE` file at the repository root. Apache 2.0 is a permissive licence with an explicit patent grant, which matters for a library you embed in a commercial product. That is a description of the licence text, not legal advice; if your organisation has a policy on permissive licences with patent clauses, run it past whoever owns that policy.

The upgrade cost is the part to think hardest about. The listed releases are all release candidates on the 8.0.0 line, and the README states plainly that APIs will still evolve. The repository does ship a `CHANGELOG.md`, and the monorepo has a `turbo.json` with `build`, `test`, `test:integration` and `test:e2e` scripts, which tells you the project takes its own verification seriously. What it does not tell you is whether a given rc will require you to regenerate your contract, and the README does not document that.

On maintenance, the facts are these: the repository is not archived, and the last push was on 2026-08-26. That is recent enough that the project is clearly being worked on, but the README's own early access notice is the more useful signal for anyone deciding whether to depend on it. A project can be pushed to daily and still be the wrong dependency for a production system, and this one says so about itself.

Editorial conclusion

Adopt Prisma Next if you are on Node.js 24 or newer, your database is PostgreSQL, and you are comfortable running early access software whose APIs the README says will still evolve. Do not adopt it for production workloads yet, and do not adopt it at all if you need MySQL, since the README lists that as coming later. Before committing, verify two things in your own checkout: that the scaffolder or `prisma orm init` leaves your framework and build setup untouched as claimed, and that the generated `prisma.config.ts` and contract under `src/prisma/` match the database you actually run.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes