Prisma Next: A TypeScript Rewrite That Turns the ORM into an Agent-Driven Tool

What Prisma Next Actually Changes

Prisma Next is not a minor version bump. The README describes it as a TypeScript rewrite of Prisma ORM, built to be extensible, composable, and AI-agent friendly by default. The core idea is that the ORM should be driven by natural language prompts through an AI assistant, rather than only by hand-written queries. The repository's default branch now points to this rewrite, while Prisma ORM 7 continues to live on the v7 branch and remains the source of the published npm packages. That split matters: if you install the stable `prisma` package today, you are not getting Prisma Next. You need the `@next` tag explicitly. This is a deliberate fork in the road, and the project is telling you that the future is the rewrite, but the present is still the old codebase.

The Mechanism: Contracts, Skills, and a Minimal Core

The architecture is visible in the installer output. When you run `prisma orm init`, it writes a `prisma.config.ts`, scaffolds a starter contract, and creates a `db.ts` under `src/prisma/`. The contract is the central artifact: it defines the data model and query surface that the agent and your application share. Alongside the contract, the installer emits a top-level `prisma-next.md` primer and one `SKILL.md` per workflow. These skills are placed in `.claude/skills/` and `.agents/skills/` so that Claude Code, Cursor, and Copilot Agent can auto-load them when your prompt matches. A `skills-lock.json` tracks installed skill versions. The flow, as described, is that you type something like "Add a posts model with a relation to users," the agent loads the `prisma-8` skill, reads the contract, and drives the change end-to-end. The extension model is equally explicit: Postgres support itself is built on the same public SPI available to any author, which means the core is intentionally thin.

Getting Started: Commands and Config Keys

The README gives two installation paths. For a new project, run `npm create prisma@next`. That interactive scaffolder picks a JavaScript framework (Next.js, Vite, Hono, and others) and wires in PostgreSQL or MongoDB. You end up with a runnable app, a starter contract, and agent skills registered. For an existing project, run `npx @prisma/cli@next orm init` from the repo root. This writes `prisma.config.ts`, scaffolds the contract and `db.ts`, installs the runtime, emits the contract, and registers the skills. It does not touch your framework or build setup. The prerequisite is Node.js 24 or newer. That is a hard requirement, not a suggestion. If you are on Node 20 or 22, which many production systems still use, this version will not run. The config file name is `prisma.config.ts`, which differs from the traditional `schema.prisma` location in Prisma ORM 7. That is a concrete migration point.

Database Support: PostgreSQL Is the Only GA Target

The README is blunt about database coverage. PostgreSQL is at general availability in Prisma 8. MongoDB is early access, described as proof that the framework works beyond SQL. SQLite is a proof of concept. MySQL is not available yet and is listed on the roadmap. This is a major limitation for teams with multi-database deployments. If you need MySQL today, this is the wrong tool. Even for MongoDB, the early access label means APIs can change without notice. The practical takeaway: treat Prisma Next as a PostgreSQL-only ORM for the foreseeable future. The project's own wording, "PostgreSQL to general availability, and that is all at this stage," is a direct warning not to assume parity with Prisma ORM 7's database support.

The AI-Agent Workflow: A Genuine Shift, But With Caveats

The core promise is that your AI assistant becomes the primary interface to the ORM. The README gives a concrete example prompt and describes how the agent loads the `prisma-8` skill, opens the contract, and makes the change. This is a real workflow, not a marketing phrase. However, it depends on your editor's AI runtime supporting the `.agents/skills/` directory. The README names Claude Code, Cursor, and Copilot Agent as expected runtimes. If you use a different editor or a custom agent, those skills may not auto-load. The `skills-lock.json` file tracks versions, but the README does not explain how to update or roll back skills. That is a gap. Also, the feedback flow for bugs relies on the agent drafting a GitHub issue or giving you a Discord link. That assumes your agent is configured to interact with GitHub, which is not guaranteed in every setup.

Extensions: The Public SPI Is the Real Test

The README emphasizes that everything, including Postgres support, sits on the public SPI. It lists four extensions already shipping: `@internal/extension-pgvector` for vector columns, `@internal/extension-paradedb` for typed BM25 indexes, `@internal/extension-postgis` for geospatial types, and `@cipherstash/prisma-next` for searchable encryption. The `@internal/` prefix on three of them is telling. Those are internal packages, not third-party modules. The only external example is CipherStash's. So the extension ecosystem is thin. The SPI is public, but the documentation for authoring extensions is a blog post, not a formal API reference. If you plan to write your own extension, you will be reading a blog and reverse-engineering the core. That is a real cost. The upside is that the SPI is the same one Prisma uses internally, so it is not an afterthought.

Maintenance and License Implications

The project is under active development, with release candidates for v8.0.0 landing daily in late August 2026. The README explicitly says APIs will evolve and the project is not recommended for production workloads yet. That has direct maintenance implications. You will need to track release candidates closely, and the `skills-lock.json` suggests that skill versions need to be updated as the core changes. The license is Apache-2.0, which is permissive for commercial use, but it does not come with any warranty or support obligation. The contribution guidelines require DCO signoff, which means each commit must be signed off by its author. If you plan to contribute, that is a process you need to follow. The security reporting path is private, not a public issue tracker. None of this is a blocker, but it sets expectations for how the project is run.

Editorial conclusion

Adopt Prisma Next if you are building new Node.js 24+ projects on PostgreSQL and want an ORM that your AI assistant can drive end-to-end, or if you plan to write custom extensions using the public SPI. Do not adopt it for production on MongoDB or SQLite, and do not migrate existing Prisma ORM 7 projects until the API stabilizes past the early access phase. Before committing, verify that your database is PostgreSQL, your Node.js version is 24 or newer, and that the agent skills integrate with your editor's runtime (Claude Code, Cursor, or Copilot Agent). The project is explicit that APIs will evolve, so pin your dependency to a specific release and track the roadmap for MySQL support.

Official sources

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