Prisma Release Notes

Why this exists

If your billing already runs through Stripe, you don't need a new vendor relationship to get a production Postgres database. Stripe Projects lets you add Prisma Postgres to your project with one command. Because the whole flow runs in your terminal, you can let your agent do it.

Coding agents have gotten good at building software but they can't provision the paid infrastructure that software needs: a database, a host, anything with a card behind it. That's the wall every agentic workflow hits: it can write the app, but it has to stop and wait for a human to go sign up, verify an email, and enter a credit card.

Stripe Projects is Stripe's answer to that wall. It's their entry into the agent-tooling race, with a distinct angle: instead of just helping agents make things, it lets them pay for them, safely, through a new primitive called Shared Payment Tokens (SPTs). Run stripe projects init and Stripe scaffolds a project for your agent: skills, a readme, and commands, plus a vault that fills with secrets as you add services. That's the starting point.

Prisma Postgres is now a provider on it. Which means an agent can go from "I need a database" to a live connection string without a human in the loop, and without a second vendor relationship, since the payment and identity you already have with Stripe carry over. And soon, full applications too, via Prisma Compute. More on that below.

Getting started

From your project directory, set up Stripe Projects:

stripe projects init

That leaves a small scaffold in your repo, the workspace your agent operates in:

.
├── .agents/skills/stripe-projects-cli/SKILL.md
├── .claude/skills/stripe-projects-cli → ../../.agents/skills/stripe-projects-cli
├── .cursor/rules/stripe-projects-cli.mdc
├── .projects/
│   ├── cache/catalog.json    # cached catalog of providers and plans
│   ├── state.json
│   └── state.local.json
├── AGENTS.md
└── CLAUDE.md

The skills and editor rules (.agents, .claude, .cursor) are what teach your coding agent to drive Stripe Projects; .projects/ holds local state. Then add a database, the step you'll usually just hand to your agent:

stripe projects add prisma/database

Your .env now has everything you need to connect:

PRISMA_DATABASE_URL = "postgres://••••••••" # direct connection
PRISMA_ACCELERATE_URL = "prisma+postgres://accelerate.prisma-data.net/?api_key=••••••••" # pooled, via Prisma Accelerate
PRISMA_DATABASE_ID = cmq••••••••
PRISMA_REGION = us-east-1

Those credentials live in two places: the canonical copy stays server-side in Stripe's Secret Store, and locally Stripe Projects keeps an encrypted copy in the project vault (.projects/vault/vault.json), with your .env as the plaintext output for local dev. Both the vault and .env are 600-permissioned and git-ignored by stripe projects init, so neither is ever committed. To onboard a teammate you don't pass secrets around: they run stripe projects env --pull and fetch their own from the Secret Store.

Notice what didn't happen: no browser opened, no signup form, no credit card. Because you have a Stripe business account, your email is already KYC-verified and tied to a real person, so we create or link your Prisma account right in the CLI (here, ✓ Prisma already linked). If you don't have a Prisma account yet, we create a claimable one from that email; if you already do, we link it and never touch your existing workspaces. Either way we spin up a new dedicated workspace for the link, and if a teammate on the same Stripe account adds Prisma too, we add them to that workspace automatically, no invites to manage.

Spending limits, the Stripe way

This is where SPTs earn their keep. An SPT is a payment credential, backed by a real payment method like a card, that carries a spending limit you set. The first time you upgrade a plan, your agent will ask you to confirm a payment method and create one for you, backed by that method. You instantiate the underlying method through Stripe's UI (the flow hands you a link), and from there you set a monthly limit, either per provider or a single global cap across everything in your project.

Here's the shape of it: your agent issues the token, hands it to the seller, and Stripe settles the charge against your limit.

The payoff: cost control isn't something each provider implements on its own, leaving you to find out it didn't work when the invoice shows up. The limit lives with Stripe and is enforced at the token, and it covers everything billed against it: both the plan subscription and any usage overages on top of it. If a plan upgrade costs more than your limit allows, it's rejected before anything changes. And as usage runs through the cycle, overage charges count against the same cap, so your total spend can't quietly climb past the number you set.

Managing your plan

There are four plans and you can see them any time with stripe projects catalog prisma:

Plan      Price    Included per billing cycle          Overages
free      Free     100k queries, 0.5 GiB-month storage None (hard limits)
starter   $10/mo   1M queries, 10 GiB-month storage    Metered
pro       $49/mo   10M queries, 50 GiB-month storage   Metered
business  $129/mo  50M queries, 100 GiB-month storage  Metered

When the free tier gets tight, upgrade from the same CLI, or ask your agent to:

# Upgrade to the Pro plan
stripe projects upgrade prisma-plan pro
# ✓ Plan price checked against your SPT spending limit first
# ✓ Workspace subscription created, billed through Stripe
# ✓ Plan applies immediately

Upgrades are immediate and before you are charged, the plan price is checked against your SPT spending limit. If it doesn't cover the price, the upgrade is rejected and nothing changes. Because the new plan takes effect right away, Stripe bills a prorated amount for the rest of the current cycle on the spot, then the full price from the next one. The plan applies to your whole Stripe Projects workspace, so every database you've added shares it.

Downgrading is the same command pointed at a smaller plan:

# Downgrade back to the free plan
stripe projects upgrade prisma-plan free
# ✓ Plan changed immediately

Plan changes through Stripe Projects are immediate in both directions: downgrades take effect right away, not at the end of your billing cycle, just like upgrades.

Day-to-day

Two commands cover most of what you'll reach for:

# Where do I stand?
stripe projects status
# Take me to my project in the Prisma Console
stripe projects open prisma

status shows what's provisioned and on which plan.

open mints a single-use link that drops you straight into your workspace dashboard in the Prisma Console, already authenticated as the right account. If you're signed into the Console as someone else, it tells you instead of silently mixing accounts. You never have to open the Console, but it's there when you want it.

Cleaning up

Tearing down is just as direct:

# Remove the database
stripe projects remove prisma-database
# ✓ Database deprovisioned immediately, access credentials invalidated
# ✗ Your plan is NOT changed. Downgrade separately if you want that

# Disconnect Prisma from this project entirely
stripe projects unlink prisma

Removing a database and changing your plan are deliberately decoupled: deleting a database never silently touches your billing. If you're removing your last database and want to stop paying, downgrade the plan too:

# Downgrade to free plan
stripe projects upgrade prisma-plan free

What's next

The database is the first piece. Prisma Compute, our TypeScript app hosting that runs on the same infrastructure as your database without sending traffic through a separate hosting vendor, recently launched in public beta and is coming to Stripe Projects next. Once it lands, the same flow gets you a deployed app right next to that database: describe an idea to your agent, and it stands up a running app with a permanent URL and a database already wired in. Then hand that URL to a colleague to try, comment on, and build on with you, all without leaving the CLI you started from. Quick revenue dashboard, internal tool, throwaway demo: it's a prompt away.

If your billing already lives in Stripe, try it:

stripe projects add prisma/database

and you're a connection string away from a real Postgres database, with a spending limit you set before we could ever bill you.

Original source

create-prisma now scaffolds Compute-ready Prisma apps with prisma.compute.ts, compute:deploy, Prisma Postgres, and Prisma Skills add-ons.

create-prisma now scaffolds apps that deploy to Prisma Compute out of the box.

Run the initializer, pick a Compute-ready template, and the generated project can include:

• Prisma schema, client helper, seed file, database scripts, and env file
• prisma.compute.ts with the app's Compute defaults
• Prisma Postgres setup, when selected
• Prisma Skills, the Prisma MCP server, and editor add-ons, when selected
• a compute:deploy script for later deploys

bun create prisma@latest

The deploy config it writes for you

For Compute-ready templates, the scaffold and the deploy defaults live in the same repo. The generated env file, app name, port, and framework drive the first deploy and every redeploy after it.

For a Hono app, create-prisma writes a config like this:

import { defineComputeConfig } from "@prisma/compute-sdk/config";
export default defineComputeConfig({
  app: {
    name: "my-api",
    framework: "hono",
    httpPort: 8080,
    env: ".env",
  },
});

That file is the whole deploy contract. For a closer look at it, including how it scales to monorepos, see Configure Prisma Compute deploys in TypeScript.

Add-ons that set your agent up

The add-ons are optional, but the Skills add-on changes how an agent works with the repo. It installs Prisma Agent Skills from prisma/skills, including the prisma-compute skill for deploys, logs, domains, and the rest of the Compute workflow.

With that in place, your agent already knows how to change the app and redeploy it. You don't have to spell out the steps in every prompt.

Redeploying after a change

A project created with create-prisma ships with prisma.compute.ts and a compute:deploy script.

After you make a change, redeploy from the project:

cd my-api
bun run compute:deploy

The script redeploys your app code using the defaults in prisma.compute.ts. Database provisioning and migrations stay outside the deploy script.

For an app you didn't scaffold, call the Prisma CLI directly:

bunx @prisma/cli@latest app deploy

Where to go next

create-prisma gets you from nothing to a deployed app and database in one command, with the config already wired up. From here:

• Read Configure Prisma Compute deploys in TypeScript to understand prisma.compute.ts and monorepo deploys in depth.
• Follow the deploy quickstart to take the generated app to a live URL.
• Browse the Prisma Compute docs for branching, environment variables, and the full CLI reference.

Compute is in public beta and free while the beta lasts. It runs your app on the same infrastructure as Prisma Postgres, which has a generous free tier of its own, so the project you scaffold today already has somewhere to run. Tell us what you build in #prisma-compute on Discord.

Original source

One file, fully typed

Prisma Compute now reads a typed prisma.compute.ts, so deploys are reproducible and monorepos work: declare one app or several, then ship the whole system with one command.

Prisma Compute can deploy a TypeScript app without config: app deploy detects the framework, builds the app, and returns a live URL.

For repeatable deploys and monorepos, Compute now reads prisma.compute.ts: a typed, committed config file for app targets and deploy defaults.

Here is the smallest useful config for a single app:

import { defineComputeConfig } from "@prisma/compute-sdk/config";
export default defineComputeConfig({
  app: {
    framework: "hono",
    entry: "src/index.ts",
    httpPort: 8080,
  },
});

Fields you set become defaults for app deploy; explicit flags still override them.

defineComputeConfig gives the file editor validation:

export default defineComputeConfig({
  app: {
    framework: "hono",
    htpPort: 8080, // Type error: did you mean httpPort?
  },
});

The CLI resolves that import when it reads the file, so deploys work without a local install. Add @prisma/compute-sdk as a dev dependency for editor types.

Declare every app in a monorepo

For a multi-app repo, use apps and key each deploy target by name:

import { defineComputeConfig } from "@prisma/compute-sdk/config";
export default defineComputeConfig({
  apps: {
    api: {
      root: "apps/api",
      framework: "hono",
      entry: "src/index.ts",
    },
    web: {
      root: "apps/web",
      framework: "nextjs",
    },
  },
});

A bare app deploy deploys every app in declaration order:

bunx @prisma/cli@latest app deploy

The output stays grouped by target:

$ bunx @prisma/cli@latest app deploy
── api (1/2) ──
Built 0.1 MB
Live in 5.9s
https://api.fra.prisma.build
── web (2/2) ──
Built 15.3 MB
Live in 16.7s
https://web.fra.prisma.build
api https://api.fra.prisma.build
web https://web.fra.prisma.build

To deploy one app, name its target or run from inside its directory. The deepest matching root wins:

bunx @prisma/cli@latest app deploy api
# or
cd apps/api && bunx @prisma/cli@latest app deploy

Compute uses your workspace package manager, resolves framework binaries in the workspace, and packages each app's dependencies. Supported targets today include Next.js, Nuxt, Astro, Hono, TanStack Start, and plain Bun servers.

Built for agents first

Agents are increasingly part of the deploy path. prisma.compute.ts keeps framework, port, env file, roots, and targets in the repo instead of only in a prompt.

Install the Compute-specific skill from prisma/skills alongside the repo:

bunx skills add prisma/skills --skill prisma-compute

Then the prompt can stay short:

Deploy this monorepo to Prisma Compute.

The prisma-compute Agent Skill gives the agent the CLI workflow for deploys, logs, domains, and explicit target choices.

What it does not do

The config declares app targets and deploy defaults. It does not select the Prisma project, branch, or production intent. Project context comes from explicit input, environment, or the local .prisma/local.json pin/cache. Branch context comes from explicit targeting, Git, or the main fallback.

Deploy output labels config-sourced settings as set by prisma.compute.ts.

A step toward one Prisma config

prisma.compute.ts is deliberately scoped, and temporary by design.

Prisma already ships prisma.config.ts for the ORM. The long-term plan is one config file for ORM, Postgres, and Compute, with Compute living under a compute key.

The shape you write today is intended to move there mechanically once the unified file is ready.

Try it

Drop a prisma.compute.ts next to your app, or one at your monorepo root, and deploy:

bunx @prisma/cli@latest app deploy

Starting fresh? create-prisma scaffolds a Compute-ready app with prisma.compute.ts already wired up.

For the full field reference, see the configuration docs. For everything else about deploying on Compute, start with the quickstart.

One config file is the point: the same repo describes your data with Prisma Postgres, your app with Prisma Compute, and your deploys with prisma.compute.ts, so a person or an agent can reason about the whole system in one place. Compute is in public beta and free while the beta lasts. Tell us what you ship in #prisma-compute on Discord.

Original source

Prisma Next gives you superpowers and makes it safe to delegate them to your agent, leaving you to focus on what matters: your app.

Define your data layer as a contract and the framework handles everything else for you: migrating your DB, type-checking your queries, and meaningful errors when something goes wrong.

Agents are here to stay. They don't replace you, they multiply your capabilities. From your first touch to your first paying user, Prisma Next's agent DX keeps your agent in the loop and on track. Instant onboarding, guardrails, verifiable type-checked work, and continuous upgrades.

Today, Prisma Next is open for Early Access for Postgres and MongoDB.

One-line setup and onboarding without any learning curve

If you've ever picked up a new framework, you know how long it takes to climb a steep learning curve. You read the docs, build a toy project and make mistakes the docs warned you about. It takes weeks to absorb the framework's idioms until you're confident enough to actually build.

One command scaffolds a new project with Prisma Next, including a family of skills which make your agent an instant expert.

npm create prisma@next

The learning curve disappears and you can start working on something meaningful straight away. Like sitting beside someone who knows their stuff, learn the framework by watching your agent execute your instructions. When you have a question, ask your agent. It knows the answer.

Write your contract, we handle the rest

If you've used Prisma before you'll recognize this:

// contract.prisma
model Book {
  id String @id @default(uuid())
  title String
  author String
  addedAt DateTime @default(now())
}

This is the contract between your application and your database. The models are what your application depends on, and your database promises to store them in the shapes described in the contract.

It's easy to read, easy to update, and it's the single source of truth for everything in Prisma Next. Queries are type-checked against it, autocomplete reads from it, and when you change it, Prisma Next plans the migrations to match, so your database continues to satisfy the contract.

That leaves you and your agent free to focus on your application.

Build fast with type-safe queries and tight feedback loops

When you're building, you know what you want, you try something, see if it works, and repeat. How fast you iterate determines how fast you ship.

Your agent runs the same loop, only its feedback comes from the contract, the type checker, structured errors, and the query builder.

Considering the book table in the contract above, you can ask the agent for a feature "add an author table with a name and bio, and link authors to books" and it updates the contract:

Then, when you ask the agent to write a query, it iterates inside its own tool calls until the query type-checks, or until it resolves any errors. Here's what that looks like in practice:

You can be confident that if the agent's query typechecks, it matches the contract and the database will support it.

Never write a migration again

If you've ever deployed an app, you've worked with migrations. Migrations are one of the most painful parts of working with a database.

You spend time getting the syntax right. Then you spend more time debugging when things go sideways. And when - not if - a migration breaks during deployment, you spend even more time fixing it while your production app is down.

In Prisma Next, instead of asking your agent to write a SQL migration (where it has all the power and a language that lends itself to simple, catastrophic mistakes) you ask it for a feature: "Add a published_at field to the Book model so I can sort by when each book was published."

The agent edits the contract to add one field. Then it asks the framework to plan the migration using:

prisma-next migration plan

The framework produces a real, reviewable TypeScript migration file alongside an authoritative ops.json. The migration.ts is reviewable authoring sugar; the framework applies the operations from the JSON.

Your agent didn't write this; the framework did. You know you can trust it because it's deterministically generated, not a creative application of SQL by your agent. Then you apply it to the database:

prisma-next migrate --db "$DATABASE_URL"

Each operation is verified before and after it executes. On Postgres, the whole migration runs in a single transaction so that if any step fails, it rolls back and the database stays exactly as it was. (MongoDB doesn't offer the same all-or-nothing DDL guarantee, so Prisma Next plans MongoDB migrations conservatively in steps that are individually safe to re-run.) Those guardrails make migrations safe for you, and that's what makes them safe to delegate to your agent.

When you need to transform data as well as change your schema, write a data migration using the same type-safe SQL query builder available in your application, with the same type-checking and safeguards.

The agent's job is to translate your intent into a contract edit. Everything else is the framework's job. You never write a migration and neither does your agent.

No more migration conflicts on parallel branches

Have you ever written a migration on one branch only to have someone else's migration merge to main while you're still working?

Now the migrations are out of order, your migration can't be applied, and you have to redo it before you can merge. Or disable safety checks and hope.

Prisma Next rethinks migration history, the same way git treats code history: each migration moves your contract from one state to the next, just like each commit moves your code from one state to the next.

When two branches add migrations from the same starting point, you get the same diamond shape git shows you in git log --graph. The CLI can render that graph for you, and the framework knows how to walk it.

Whenever you work with people on multiple branches, this is bound to happen. When you have multiple agents working in multiple worktrees or branches, it happens even more often.

The prisma-next-migration-review skill teaches your agents to understand this graph. When a new migration reaches main while your agent's mid-feature, the agent reads the graph, rebases its branch, and re-runs migration plan. The framework re-plans the migration against the new main.

That's the same flow the agent ran the first time, just against the updated main. The migration that comes out fits on top cleanly. No special procedure to learn, no human in the middle, no --force with fingers crossed. Run as many features in parallel as you have agents for them.

We're shipping every day so we made upgrades easy

When a new version lands, simply tell your agent to "upgrade prisma next".

Agent running prisma-next-upgrade
→ Loaded prisma-next-upgrade skill
→ Detected current: 0.10.0    target: 0.11.0
→ Reading upgrades/0.10-to-0.11/instructions.md
→ Plan: wrap single-row .insert({...}) calls in arrays
→ Bumping @prisma-next/* to 0.11.0 in package.json
$ pnpm install
✓ Lockfile updated
→ Applying codemod across src/
✓ Updated 3 files
$ pnpm typecheck && pnpm test
✓ Type check passed, tests green
$ git commit -am 'chore: prisma-next 0.10 → 0.11'

And we want your feedback, and your agent knows how to get it to us.

If you find a bug, or something you feel is missing, ask your agent to tell us about it: "this is a bug" or "this should be a feature" or "how should I do X?". It will pick the right channel, draft a structured, public-safe report, and file it on your behalf with your confirmation.

Try it out

Prisma Next brings Prisma's world-class DX to your agent, so you can focus on building your app. Stay hands-on, let your agent take over, or switch mid-flow. With Prisma Next, you can delegate with confidence.

To try it today in a fresh project, run:

npm create prisma@next

To add Prisma Next to an existing project, run:

npx prisma-next@latest init

From there, just ask your agent to build something:

"Build me a small app that tracks the books I'm reading. Add a few records, and show me the list."

Or ask your agent anything about Prisma Next:

"What happens if a migration fails during deployment?"

"How do I handle breaking changes in my code?"

Once you've got something running, tag us on X and tell us what you built. The best community builds get a shout-out from the Prisma account and a link in the Prisma Next README.

And when you're ready to ship it, our hosted database Prisma Postgres comes with a generous free tier.

Star and watch prisma/prisma-next on GitHub to follow what ships next. And if you hit a snag, start a thread in #prisma-next on our Discord.

We can't wait to see what you build.

Note that Prisma Next is not production-ready yet. Prisma 7 is still the right choice for production applications today. When Prisma Next is ready for general use, it will become Prisma 8.

Original source

In March we published the Prisma Next roadmap

April was the month we'd open Prisma Next up to external contributors. May was the month we'd put it into users' hands.

The April milestone is complete. The extension API is open to outside authors.

Four extensions now ship on it: pgvector, arktype-json, ParadeDB, and CipherStash. One planned piece did not land: streaming subscriptions in the runtime. May shifts to Early Access for users.

If you want to build a Prisma Next extension, the call for extension authors is the front door. The API will keep evolving, but it's stable enough to build something real against — and we want to hear what's missing.

What you can build with the extension API

An extension can contribute new data types, new query operations, and new migration logic. The first four cover that range:

• pgvector adds vector types and similarity queries to your Postgres schema.
• arktype-json lets you store and query typed JSON columns with ArkType validation.
• ParadeDB adds full-text and analytical search backed by ParadeDB's Postgres extensions.
• CipherStash adds searchable encryption at rest — encrypted column types with query operations on encrypted values, built by the CipherStash team.

These are built on the same extension API the Prisma Next team uses for built-in features. If you want to see what an extension looks like end to end, the upcoming build-your-own-extension tutorial walks through a small one from scratch.

What else landed in April

Extensions are the headline, but the rest of the stack moved too. Here's what you can do now that you couldn't a month ago.

Migrations

You can author migrations in TypeScript. Scaffold a migration file, write the change in code, and the compiler emits a structured description the runner picks up and applies. TypeScript migrations in Prisma Next walks through the authoring surface.

Data migrations are partly there. You can run a data transformation — say, splitting name into firstName and lastName — and the system records what changed and what guarantees the migration leaves behind ("every row now has a non-null email"). What still needs to land: the runtime using those guarantees, so queries can take advantage of them automatically. That part carries into May. Data migrations in Prisma Next covers this in detail.

Contract authoring

You can define your data contract in contract.prisma or in TypeScript. Both surfaces produce the same compiled contract, regardless of which you choose. Next up: the everyday helpers, IDE autocomplete, and the patterns a first-time user expects to work without thinking.

Transactions and React Server Components

Transactions work on Postgres. The ORM can open a transaction, and the SQL query builder can run inside it, sharing one database connection — so the SQL escape hatch actually works mid-transaction.

The runtime runs safely under React Server Components: parallel Server Components, shared runtime state, connection pooling, and query-result caching all behave correctly under concurrency.

Middleware hooks are in place — a middleware function can see a query, return a cached result, or rewrite the response.

MongoDB

MongoDB is a first-class database family in Prisma Next. You get type-safe queries, real database migrations (indexes, JSON Schema validators, collection options), polymorphic collections with discriminated unions, embedded documents, and a typed aggregation pipeline builder. MongoDB Without Compromise covers the full story.

SQLite

We built a SQLite proof of concept that shows how straightforward it is to add more database targets to Prisma Next. More targets will roll out in the coming months, but right now our focus is Postgres and MongoDB.

What did not land

Streaming subscriptions didn't make it in April, but they will in May.

For our upcoming Supabase support, we're adding realtime query subscriptions — an adapter that receives a stream of changes from the database, a subscribe() call in the runtime, cancellation and cleanup, and change events flowing through middleware.

May: making it easy to get started

May's focus is the developer experience. We want your first hour with Prisma Next to feel smooth, from scaffolding a project to running your first query. When it's ready, we'll launch Prisma Next as Early Access for Postgres and MongoDB.

Three things to watch this month:

• Getting started gets smoother. Project scaffolding, db init, db update, CLI consistency, error messages that tell you what to do next. Contract authoring picks up the patterns you'd reach for on day one — scalar arrays, composite keys, @updatedAt, native type annotations — and the language server stops showing false errors on valid Prisma Next schemas.
• The query and migration surfaces keep maturing. Transactions extend to SQLite and MongoDB. The SQL query builder covers more real-world escape-hatch patterns. The migration workflow gets clearer output, smoother manual migration UX, and preflight verification.
• New platform support. First-class Supabase support, including realtime query subscriptions. Cloudflare Workers ships as a first-party Postgres module.

Try it out

You can start building with Prisma Next today. Run npx prisma-next init, open the contract, add a model, run prisma-next migration plan — it takes about as long as reading this paragraph.

The API is still settling, so expect breaking changes often. If you find rough edges or something you were hoping for that's missing, drop into #prisma-next on Discord and tell us. Feedback right now is the most valuable thing we can get.

Star or watch prisma/prisma-next on GitHub to follow updates as they land, and subscribe to the Prisma blog for the monthly milestone update.

Prisma Next is not yet production-ready. Prisma 7 remains the right choice for production today, and when Prisma Next is ready for general use, it becomes Prisma 8.

Further reading

Planning and status documents live alongside the code in prisma/prisma-next:

• Previous roadmap post — what we said in March
• April milestone plan — what April was for
• May milestone plan — what May is for
• Runtime April status and May handoff — detailed carry-overs

April moved through more than 2,000 commits in prisma/prisma-next, concentrated across framework, SQL, MongoDB, targets, extensions, examples, integration tests, and architecture docs.

Original source

If you've ever wanted to integrate your tool, your database, or your library with Prisma, or you tried in Prisma 6 or 7 and gave up, this post is for you. Read the Prisma Next Early Access announcement for the full launch story.

Prisma Next has a deliberately tiny core that knows nothing about any specific database. Postgres support is an extension. Vector search is an extension. JSON-with-schema is an extension. Whatever Prisma Next can do, it does because someone wrote it using the same components that are available to you.

The API surface is real, the same shape we used to build Postgres support ourselves, and ready to build against today.

Postgres is an extension

The Prisma Next framework knows about contracts, plans, query lifecycle, and the policies that gate execution. It does not know what Postgres, SQL, Mongo, vectors, or any column type other than unknown are.

Every database we support and every native feature you've used in Prisma Next was added by an extension package on a public service provider interface (SPI). The Postgres target, the SQL family (its contract shape, operations, and lanes), the Postgres adapter and driver, the pgvector vector type and its similarity operators, and the arktype-JSON codec are all extensions.

There is no "core API" and "plugin API." There is one SPI, used by the team building Prisma Next and by anyone shipping a package today. Anything we build, you can build alongside us or in place of.

What an extension can ship

An extension is a normal npm package: @yourname/prisma-next-extension-foo. Your users pnpm add it, add one line to prisma-next.config.ts, and your additions show up in their contract, their queries, and (if you ship migrations) their migration plans.

An extension can include any subset of four layers, in any combination:

• Contract layer: column types, field builders, index types, and authoring constructs that show up in contract.ts and contract.json with your namespace and your validation rules. This is how pgvector adds dimensioned vector columns and how ParadeDB adds typed BM25 indexes
• Query layer: typed methods on the query builder. Users discover them through autocomplete; they compile to SQL via lowerers you provide. This is how pgvector adds cosineDistance on vector columns
• Runtime layer: codecs that translate between the database wire format and your TypeScript types. Codecs can be synchronous (pgvector vectors decode to number[]) or asynchronous (encryption codecs decrypt on read with key material from an external service). Runtime middleware is also part of this slice, covering observability, audit, and policy interception around every query
• Migration layer: custom DDL and data operations with pre/post checks and idempotency declarations, integrated into the migration planner. ParadeDB's planned BM25 index ops land here, and so does anything else that needs to participate in the migration graph rather than ship as a one-off script

Pick the layers you need. A useful extension can be one layer (a single codec, a single index type) or all four for a full vertical slice.

Real extensions you can copy

Three extensions ship in the repo today, each demonstrating a different combination of layers. Each one is a starting template you can copy, rename, and change.

pgvector: three layers in one pack

@prisma-next/extension-pgvector is the canonical example. It ships a vector(N) column type on the contract layer, cosineDistance and cosineSimilarity operators on the query layer, and the codec that maps the SQL vector type to number[] on the runtime layer.

All three show up in the same project, file by file:

// prisma-next.config.ts: register the pack
import pgvector from "@prisma-next/extension-pgvector/control";
export default defineConfig({
  family: sql,
  target: postgres,
  adapter: postgresAdapter,
  extensionPacks: [pgvector],
});

// prisma/contract.ts: declare a dimensioned vector column
import { vector } from "@prisma-next/extension-pgvector/column-types";
const Post = model("Post", {
  fields: {
    embedding: field.column(vector(1536)).optional(),
  },
}).sql({ table: "post" });

// app code: use cosineDistance as a typed method on the column
const plan = sql.from(tables.post).select({
  distance: tables.post.columns.embedding.cosineDistance(param("q")),
}).orderBy(tables.post.columns.embedding.cosineDistance(param("q")).asc()).limit(10).build({ params: { q } });

arktype-json: codec and contract layers, library-author shape

@prisma-next/extension-arktype-json is a per-library codec for JSON-with-schema columns. Pass it an arktype schema and you get back a typed JSON column whose TypeScript type matches the schema ({ name: string; price: number }) and whose values are validated against the schema on the wire.

The pattern is deliberately per-library: arktype-json today, zod-json and valibot-json on parallel tracks tomorrow, each shipping the same shape with their own serialize/rehydrate story. This is the natural template for the integration you've probably wanted: your TS library wired up at the contract layer, not bolted on around the edges of an ORM.

ParadeDB: contract layer only

@prisma-next/extension-paradedb adds typed BM25 full-text-search index authoring for ParadeDB users: bm25.text(...), bm25.numeric(...), and bm25Index({ ... }) with all twelve built-in tokenizers and validation against the BM25 contract.

The query and migration layers for ParadeDB are explicitly planned, not yet shipped, and the README says so out loud. We think that's worth saying: an extension doesn't have to ship every layer at once. Authoring-first and following with the rest is a perfectly good trajectory, and the surface supports it.

What you might build

Prisma Next was built to be extensible from day one, and there are an endless number of possibilities for what you could build with it. Here are some starting points:

• Database-extension authors: a PostGIS pack with geospatial column types, spatial operators, and CREATE EXTENSION postgis in migrations; a pg_trgm pack for trigram similarity and fuzzy text search; a pg_partman pack for native partitioning
• Library authors: a zod-json extension; a valibot-json extension; a Sentry or OpenTelemetry middleware for production observability
• Database and wire-protocol authors: an alternative SQL target with your dialect, your adapter, and your driver, on the same composition surface as Postgres; an Atlas Search target for MongoDB users
• Internal platform teams: a company-wide @yourcompany/prisma-next-platform capability pack that ships your typed JSON columns, your audit middleware, your row-level access policies, and your shared contract conventions as a single install

If your shape is on this list, the closest existing extension is your starting point. If your shape isn't, we'd like to hear about the gap.

What we'll do for you

If you build something we'd want to install ourselves, we'll do the work to put it in front of the Prisma userbase:

• A featured post on the Prisma blog, written with you, describing what you built and why it matters
• Promotion through Prisma's social channels, where the audience is exactly the developers most likely to install your extension
• A spot in the upcoming Prisma Next extensions directory, where users will go to discover what's available

Prisma's userbase is large. For an integrator (a database company, a library author, a security or observability tool), being featured in front of that audience is real distribution.

And if you're a Prisma user reading this, not an integrator yourself: think about the tools you already use that don't have a Prisma integration today. Send them this post. Tell their team that there's never been a better moment. Many of the integrations we'd most like to see will only happen because someone made the connection.

We, the Prisma Next team, are available on Discord and eager to help you build, as we have with ParadeDB and Pothos already.

The fastest way to start

Clone prisma/prisma-next, point your coding agent at the repo, and tell it what you want to build.

The repo is dense with architecture docs, architecture decision record (ADRs), SPI READMEs, and reference extensions: enough context that an agent can absorb it in seconds and scaffold a working pack from your description alone, without you reading a line of it first.

The result is normal TypeScript you can read, edit, and iterate on like any other code, and it's dramatically faster than building one by hand from documentation.

If you'd rather start from a known-good template yourself, pick the existing extension closest to what you want and copy it:

• Building a feature pack with column types, operators, and codecs? Copy pgvector
• Integrating a TypeScript library at the contract layer (validation, serialization, schema-driven types)? Copy arktype-json
• Adding typed authoring for a database feature, with the rest of the layers to follow later? Copy ParadeDB

Either way, the packages are small. Reading code is faster than reading docs.

Build an extension

Build it, then tell us about it in #prisma-next on Discord, and star prisma/prisma-next on GitHub to follow the SPI as it matures.

Prisma Next is early, and the SPI is stable enough that the existing extensions are real proof of what's possible, though we expect to iterate as more of you build against it.

Prisma 7 remains the right choice for production today, and Prisma Next will become Prisma 8 once it's ready for general use.

The most interesting extensions will be the ones you'll write.

Original source

create-prisma is a new CLI that creates an app with Prisma set up, including a starter schema, seed data, database scripts, and optional Prisma Postgres setup.

Starting a new app should be quick.

You know what you want to build, so you pick a framework and a database, but before you can work on the app itself you still need to set up Prisma, add a schema, add database scripts, create a seed file, set DATABASE_URL, generate Prisma Client, and run a migration.

Today, we're introducing create-prisma, a CLI that creates a new app with Prisma already set up.

npm create prisma@latest

Pick a template, pick a database, and start with a working Prisma app.

Why we built it

Prisma setup is simple, but every framework is a little different.

Next.js, Nuxt, SvelteKit, Hono, NestJS, TanStack Start, and Turborepo do not all put Prisma files in the same place. Some apps need a Prisma client helper in src/lib. Some need it in a server folder. A monorepo may need Prisma in a shared package.

create-prisma handles those details for you.

Create a Hono API with PostgreSQL:

npm create prisma@latest --name my-api --template hono --provider postgresql
cd my-api
npm run dev

Or create a Turborepo where Prisma lives in a shared database package:

npm create prisma@latest --name my-monorepo --template turborepo --provider postgresql

Templates are available for Hono, Elysia, NestJS, Next.js, SvelteKit, Astro, Nuxt, TanStack Start, and Turborepo.

What you get

The generated app includes the Prisma files and scripts you need:

• prisma/schema.prisma
• prisma/seed.ts
• prisma.config.ts
• db:generate, db:migrate, and db:seed scripts
• a Prisma client helper
• a .env file with DATABASE_URL

By default, it also includes a small User model, seed data, and an example query in the app. So the first thing you see is not just "Prisma is installed." You can run the app and see it talk to the database.

It can create a database too

If you choose PostgreSQL and do not provide a DATABASE_URL, create-prisma can create a Prisma Postgres database for you:

npm create prisma@latest \
  --name my-app \
  --template next \
  --provider postgresql \
  --prisma-postgres

The CLI writes the connection string into .env. It can also generate Prisma Client, run the first migration, and seed the database.

Databases created this way are temporary for 24 hours until claimed. That makes it easy to try an idea quickly and keep the database if the project becomes real.

Optional AI and editor setup

create-prisma can also set up Prisma tools for your editor and AI coding agents:

npm create prisma@latest \
  --name my-app \
  --template next \
  --provider postgresql \
  --skills \
  --mcp \
  --extension

These add-ons can install Prisma skills for coding agents, configure the Prisma MCP server, and install the Prisma extension for supported editors.

Try create-prisma today:

npm create prisma@latest

You can find the project on GitHub at github.com/prisma/create-prisma.

Original source

For the first time, Prisma Next brings the MongoDB-native experience to TypeScript.

Type-safe queries, database migrations, polymorphic models, embedded collections and more. Designed in collaboration with the MongoDB DX team.

What MongoDB development looks like today

If you've built a MongoDB app with TypeScript recently, you've probably gone through some version of this:

• You define your application types in TypeScript so the compiler understands your data.
• You set up Mongoose or the native driver and define those shapes again in a different format.
• You write a query and the types don't fully connect, so you cast, add guards, or accept a little any.
• You need an index, so you drop into the MongoDB shell or a deployment script and hope your database stays in sync with your code.

In Prisma Next, you describe your data model as a contract:

model User {
  id ObjectId @id @map("_id")
  name String
  email String
  bio String?
  address Address?
  posts Post[]
  @@map("users")
}
type Address {
  street String
  city String
  zip String?
  country String
}
model Post {
  id ObjectId @id @map("_id")
  title String
  content String
  kind String
  authorId ObjectId
  createdAt DateTime
  author User @relation(fields: [authorId], references: [id])
  @@discriminator(kind)
  @@index([authorId])
  @@index([createdAt], { sort: -1 })
  @@map("posts")
}
model Article {
  summary String
  @@base(Post, "article")
}
model Tutorial {
  difficulty String
  duration Int
  @@base(Post, "tutorial")
}

From this contract, Prisma Next derives everything: TypeScript types, query validation, migration plans, and discriminated unions for polymorphic collections.

Type-safe queries

All queries and their results are type checked in Prisma Next. If you miss a required field, TypeScript tells you, and the result types flow through your application logic from database to UI.

const alice = await orm.users.create({
  name: 'Alice Chen',
  email: '[email protected]',
  bio: 'Full-stack engineer and tech blogger',
});
const recentPosts = await orm.posts.where((post) => post.createdAt.gte(lastWeek)).orderBy((post) => post.createdAt.desc()).include('author').all();
// recentPosts[0].title -> string
// recentPosts[0].author.name -> string
// recentPosts[0].author.bio -> string | null

The .include('author') compiles to a $lookup pipeline stage. Skip the .include() and the author isn't loaded and isn't in the type. Your documents are typed all the way down, no matter how far you nest.

Real migrations for MongoDB

MongoDB is not schema-less. Your deployment has real, persistent, server-side state, and that state directly affects correctness and performance. Yet most tools do not manage it properly.

The @@index declarations in the contract above are not just documentation. They are managed by a migration system that versions, diffs, and deploys your database state.

• Indexes: unique, compound, TTL, partial, geospatial, text, and wildcard. If an index is wrong, queries slow down. If a unique constraint is missing, duplicate data can slip in.
• JSON Schema validators: document-level validation rules generated from your model definitions. Even writes that bypass the ORM are still validated by the server.
• Collection options: capped collections, time series configuration, and collation settings.

When you update your contract and run prisma-next migration plan, the planner compares the current state with the desired state:

$ prisma-next migration plan
Migration: 20260409T1200_add_post_indexes
Create index on posts (authorId)          [additive]
Create index on posts (createdAt, desc)   [additive]
2 operations.
Run `prisma-next migration apply` to execute.

It includes pre-checks, post-checks, full history, branching, and rollback, following the same structure as Prisma Next's SQL migrations. Your indexes, validators, and collection options are versioned alongside your code and deployed through CI/CD.

The MongoDB Node.js Driver team identified the lack of migration tooling as a key source of friction in their user research. Until now, developers did not have proper tooling to manage MongoDB's server-side state as a versioned deployable artifact.

Data migrations are coming too, and will give MongoDB developers managed tooling for transforming data while performing migrations.

Polymorphic collections with discriminated unions

The MongoDB Node.js Driver team rated inheritance and polymorphism as the highest-priority gap for TypeScript tools working with MongoDB.

Polymorphic collections are a standard MongoDB pattern, and most tools handle them poorly. Variant-specific fields become optional or any, or you split into separate collections and lose the ability to query across all documents.

Look at the @@discriminator(kind) on Post and the @@base declarations on Article and Tutorial in the contract above. From these, Prisma Next generates TypeScript discriminated union types. When you query all posts, you get the full union. When you query a variant, the return type narrows:

const posts = await orm.posts.all();
// Each post is Article | Tutorial — a discriminated union on `kind`
const articles = await orm.posts.variant('Article').all();
// articles[0].summary -> string (not optional, not any)

Standard TypeScript narrowing works on the results. The same if (post.kind === 'article') you'd write by hand, but now verified against your contract:

for (const post of posts) {
  if (post.kind === 'article') {
    console.log(post.summary);
  }
  if (post.kind === 'tutorial') {
    console.log(post.difficulty);
    console.log(post.duration);
  }
}

Polymorphism connects to migrations too. An index on a variant-specific field, difficulty on Tutorial for example, automatically gets a partialFilterExpression derived from the discriminator, scoping the index to only documents where kind === 'tutorial'. The contract declares the full relationship between variants, discriminator values, and fields. No manual configuration.

A note on versioned documents:

A common MongoDB pattern is versioned documents. A version field determines which fields apply. In Prisma Next, this is just a polymorphic model with version as the discriminator. Each version is a variant with its own typed fields. No special-case reading logic, no long-running data migration, no downtime.

Typed aggregation pipelines

When you need MongoDB's aggregation pipeline for grouping, projecting, or faceting, Prisma Next provides a typed pipeline builder:

const { pipeline, runtime } = orm;
const leaderboard = pipeline.from('posts').group((f) => ({
  _id: f.authorId,
  postCount: acc.count(),
  latestPost: acc.max(f.createdAt),
})).sort({ postCount: -1 }).lookup({
  from: 'users',
  localField: '_id',
  foreignField: '_id',
  as: 'author',
}).build();
const results = await runtime.execute(leaderboard);

Field references like f.authorId and f.createdAt check against your contract. Misspell a field name and you get a compile-time error, not a runtime $group failure:

.group((f) => ({
  _id: f.authrId, //     ~~~~~~ Property 'authrId' does not exist on type 'PostFields'
}))

When the pipeline builder doesn't cover what you need, you can drop to raw MongoDB commands:

const raw = orm.raw.collection('posts');
const results = await runtime.execute(
  raw.aggregate([
    { $match: { kind: 'article' } },
    { $sample: { size: 5 } },
  ]).build()
);

Full control, same runtime.execute entry point. ORM for most queries, typed pipeline builder for aggregation, raw commands as the escape hatch: the same layered approach Prisma Next uses for SQL.

How Prisma Next compares to other tooling

The ORM ecosystem has plenty of healthy competition, and we wanted to make sure Prisma Next stands out with a clear reason for developers to adopt it.

Concern Raw mongodb driver Mongoose Prisma ORM (current) Drizzle Prisma Next Schema definition ❌ None 🟡 JS schemas, partial TS 🟡 Prisma schema (no embedded docs) ➖ N/A (SQL only) ✅ Prisma contract (full embedding, polymorphism) Type safety (queries) 🟡 Top-level only 🟡 Partial (FilterQuery -> any) 🟡 Generated (no embedding) ➖ N/A ✅ Full (filters, operators, nested) Type safety (mutations) ❌ None 🟡 Partial 🟡 Generated types ➖ N/A ✅ Full (including MongoDB operators) Embedded documents ✅ Native ✅ Native ❌ Not supported ➖ N/A ✅ First-class in contract Polymorphism / unions 🟡 Native (untyped) 🟡 Discriminator plugin ❌ JSON fallback ➖ N/A ✅ Discriminated unions (@@discriminator / @@base) Referential integrity ❌ None 🟡 Manual (middleware) ❌ None ➖ N/A 🔲 Planned (cascade, restrict, setNull) Aggregation pipelines 🟡 Untyped arrays 🟡 Untyped arrays ❌ Not exposed ➖ N/A ✅ Typed pipeline builder Cross-family support ➖ N/A ➖ N/A 🟡 SQL + Mongo (separate) ❌ SQL only ✅ SQL + Mongo (shared patterns) Schema migrations (indexes, validators) ❌ Manual scripts ❌ Manual scripts ❌ No Mongo migrations ➖ N/A ✅ Graph-based migration system Data migrations ❌ Manual scripts ❌ Manual scripts ❌ No Mongo migrations ➖ N/A 🔲 Coming Middleware ❌ None 🟡 Mongoose plugins 🟡 Limited ❌ None for Mongo ✅ Full (shared with SQL)

✅ strong / native, 🟡 partial / manual, ❌ missing / none, 🔲 planned, ➖ not applicable

Where we are, where we're going

Prisma Next is still in its early stages and isn't ready for production use yet. For production applications, Prisma 7 is still the recommended choice. Once Prisma Next is ready for general use, it will become Prisma 8, and upgrading will be a smooth process.

What works today:

• Prisma contract for MongoDB with embedded types, cross-collection references, and polymorphism
• Typed ORM client: CRUD, $lookup-based includes, .variant() queries, filters, and ordering
• Schema migrations: indexes, JSON Schema validators, and collection options deployed through CI/CD
• Typed aggregation pipeline builder

What's coming:

• Data migrations for MongoDB
• Configurable referential integrity: cascade, restrict, and setNull
• Extension packs for Atlas Search and geospatial queries

The MongoDB Node.js Driver team's input from user-journey research and feature-gap analysis directly shaped this work, from identifying polymorphism as the highest-priority gap to highlighting schema management as a major source of friction.

We believe this raises the bar for what MongoDB developers should expect from their tools.

• Star + watch the repo: github.com/prisma/prisma-next
• Try the Mongo demo app: examples/mongo-demo
• Join the conversation: Discord

Original source

What we learned from Prisma Optimize

Prisma Optimize has evolved into Query Insights in Prisma Postgres.

Read the Query Insights announcement.

We're sunsetting Prisma Optimize to make room for Query Insights. Query Insights is built right into Prisma Postgres and removes the friction that Optimize introduced. Let's look into what lead us to this decision and what this means for your projects.

In recent rounds of user feedback, we asked users of Optimize what their pain points were with the feature. In those conversations, a few patterns became clear:

• Adding a client extension for monitoring introduced friction, especially across runtimes and environments.
• Visibility into SQL queries was limited, and teams wanted more direct insight into what was happening at the database level.
• AI recommendations lacked SQL context, which made it harder to connect suggestions to the underlying query behavior.
• Profiling felt too manual, with recording workflows that were heavy for quick investigations.

All of this pointed to the same conclusion: query observability should be automatic, not something you have to wire up yourself.

Introducing Query Insights

Query Insights is built directly into Prisma Postgres and automatically provides analytics about your queries without requiring client extensions or additional setup.

Simply open your Prisma Postgres dashboard and go to the Queries tab.

For existing Prisma Optimize users

If you previously installed Prisma Optimize, you can safely remove it.

1. Uninstall the package:

bun remove @prisma/extension-optimize

1. Remove the extension from your Prisma Client setup:

import { PrismaClient } from '@prisma/client'
-import { withOptimize } from '@prisma/extension-optimize'
const prisma = new PrismaClient()
.prisma.$extends(withOptimize())

Query Insights is available now as part of Prisma Postgres without extra setup, and will be launching more broadly soon.

Stay tuned for the official launch.

Original source

On March 4th we introduced Prisma Next, the future of Prisma ORM. We made the repo public so you can follow progress. We shared some of what we've built so far and what's in the works, including:

• a brand new query API with custom collection methods for your models
• streaming query results
• a low-level, type-safe SQL query builder (an escape hatch for complex or custom SQL queries)
• extensions that let you install new behaviors and data types (including the first extension example: pgvector)
• support for TypeScript Prisma schemas as an alternative to the traditional schema.prisma, so you can pick which you prefer
• middleware, validations, query linting, and lots more

There's a lot still to do, so to make sure we can get Prisma Next into developers' hands as soon as possible, we're delivering the remaining work in phases.

April: Enable external contributions

We want external contributors to be able to add new Prisma Next features, like:

• SQL database targets
• Postgres extensions
• middleware for telemetry, error reporting, and query checks
• new query builders
• validator integrations (like Zod and Arktype)
• integrations with services like Sentry and Datadog
• integrations with popular frameworks like Next.js and Vue.js

These are just some of our ideas and we want to open Prisma Next to hear your ideas.

We're currently focused on developing stable APIs for extension points, establishing reliable interfaces for extension authors, and validating core framework concepts.

In April, we'll put out a public call inviting collaborators to join us to extend Prisma Next. We will work with you during April to implement your extensions and polish the small things we inevitably got wrong.

We're already working with the MongoDB and ParadeDB teams on POCs to validate that the architecture genuinely supports non-SQL targets and extension-provided database primitives.

If you want to get in early and help shape the final version of Prisma Next, April is the time to get involved.

May: Early access

Next, we want to get Prisma Next into users' hands. We need to see how it holds up in real-world applications, so we'll follow our normal EA process: an initial release, a period of feedback and refinement, then General Availability.

As soon as it's ready, we'll put out a public announcement alongside getting started material and guides explaining the key differences between Prisma 7 and Prisma Next.

By this point we expect the user-facing APIs to be stable for Postgres and one additional SQL database (SQLite is our top pick).

If you want to adopt Prisma Next early, May is the time to get started. Prisma Next Early Access is now live.

June - July: Postgres General Availability

Between the EA release in May and July, we want to bring Prisma Next Postgres support to GA, giving it our stamp of approval as a production-ready product. Prisma 7 will continue to receive long-term support for teams that want a fully battle-tested foundation.

For teams looking to upgrade, you'll be able to run Prisma Next and Prisma 7 in parallel and gradually shift traffic from one to the other. We'll also provide a compatibility layer so you don't need to immediately rewrite all your queries.

Follow along

For the most up-to-date view, follow the roadmap in the Prisma Next repo as it develops in real time. We'll post announcements like this one as we learn more.

For the broader picture, check out the Prisma Next repo and star it to subscribe to updates.

Original source

If you haven't noticed yet, we recently rebuilt the Prisma documentation site from the ground up. It's been a massive undertaking, and we're excited to share some of the details behind it.

Documentation is a key part of any software project. If your documentation isn't up to par, people won't use your library. At the same time, people are accessing documentation in new ways through agents and AI-assisted tools. Documentation should support both formats and be clear for both humans and machines.

We took on the effort to rebuild the Prisma docs without disrupting everyone's day-to-day work. This included rebuilding the site with a different documentation framework and reviewing all the content that had been in the docs for years. The new Prisma docs bring a fresh coat of paint to the whole experience and make learning about Prisma more enjoyable.

Why rebuild?

Like many open source projects, our docs had grown fast. When features shipped, docs followed quickly. That's mostly good, but over time the structure became harder to navigate and harder to trust — meaning outdated or duplicated content was easy to miss.

Duplicate content spread across pages. Related topics ended up isolated. If a community member updated one section, it was easy to miss similar content elsewhere.

The goal was simple: make the docs easier to maintain, easier to trust, and easier to improve.

Starting with the content

Before touching any code, we mapped what existed. We organized everything into four main sections:

• Getting Started
• ORM
• Prisma Postgres
• Guides

From there, we reviewed each section: removing outdated content, flattening navigation, and eliminating duplicate pages. Instead of landing on overview pages with links to subsections, we wanted users to land on a section and immediately get what they need.

We also standardized code patterns across the docs. Formatting, command examples, and section structure became consistent throughout.

Quality tooling improved in parallel. Link checks, linting, and review workflows all got tighter, making publishing safer and review cycles faster.

A new engine: Fumadocs

A big motivation for the rebuild was discovering Fumadocs, a framework built specifically for documentation. It provides:

• A content system for structured docs
• UI components out of the box
• Search and AI chat integration
• Flexible customization

When we evaluated it as a team, our old docs immediately felt dated by comparison. So we went all in: not just a framework swap, but a full redesign of the UI, colors, and fonts.

We also surfaced Search and Chat with keyboard shortcuts, Cmd-K for search and Cmd-I for chat.

Better search and chat

Search now runs on Mixedbread (an AI search provider), which uses AI models to return more accurate results based on your query, not just keyword matching.

AI Chat still uses Kapa.AI, but we replaced their default widget with a custom sidebar that persists conversations between sessions. Close the browser, come back later, and your conversation picks up where you left off.

Versioned docs

Fumadocs also let us properly version the docs for the first time. Prisma v6 has a dedicated section covering its full API. Prisma v7 stays clean and current with no version callout banners cluttering the content.

Launching without disrupting

The launch happened in stages, not all at once.

The initial work was done in a private repo. Before merging, we:

1. Disconnected automatic deploys from the old repo
2. Kept the existing site live as a static deployment
3. Merged the new structure into the main Prisma Docs repo
4. Deployed to a new host and validated everything worked

Then we went straight into monitoring: tracking every 404, watching for runtime errors, and addressing SEO issues as they surfaced.

What changed for users and contributors

For users:

• Content is easier to scan and navigate
• Paths are cleaner
• Older links are covered by redirects

For contributors:

• Clearer structure and workflow for contributors
• Stronger quality checks
• Smoother review cycles
• Less back-and-forth means updates ship faster

The biggest outcome is a lower maintenance cost for every future update.

Lessons learned

1. Start with structure. Content moves faster when navigation and URLs are stable.
2. Plan for cleanup. Migration always surfaces more to fix than expected.
3. Turn feedback into tasks quickly. Comments alone don't scale.
4. Treat launch as an operational phase. Redirects, monitoring, and communication are part of shipping.
5. Keep the momentum post-launch. That's where quality improves most.

The rebuild worked because we treated the docs as product infrastructure, not a one-time writing project. If you're planning something similar: stabilize the structure first, ship in controlled steps, and dedicate real time to post-launch stabilization.

Original source

Prisma ORM v7.7.0 introduces a new prisma bootstrap command that sequences the full Prisma Postgres setup into a single interactive flow.

It detects the current project state and only runs the steps that are needed:

1. Init or scaffold: In an empty directory, offers a choice of 10 starter templates from prisma-examples. In an existing project without a schema, it runs prisma init.
2. Link: Authenticates via the browser and connects to a Prisma Postgres database. Skips if the project is already linked.
3. Install dependencies: Detects the package manager and offers to install missing @prisma/client, prisma, and dotenv.
4. Migrate: Runs prisma migrate dev if the schema contains models.
5. Generate: Runs prisma generate.
6. Seed: Runs prisma db seed if a seed script is configured.

Each side-effecting step prompts for confirmation, and re-running the command skips any steps that are already complete.

This feature shipped in #29374 and #29424.

Basic usage

npx prisma@latest bootstrap

With a starter template

npx prisma@latest bootstrap --template nextjs

Non-interactive (CI)

npx prisma@latest bootstrap --api-key "$PRISMA_API_KEY" --database "db_abc123"

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

Original source

Features

CLI

• #29352: Added a new prisma postgres link command that connects a local project to a Prisma Postgres database.

This is the first command in a new prisma postgres command group for managing Prisma Postgres databases directly from the CLI.

Driver Adapters

• #29395: @prisma/adapter-pg adds a statementNameGenerator option for custom prepared statement naming and pg statement caching
• #29287: @prisma/adapter-pg now supports passing connection strings directly to the constructor
• #29392: @prisma/adapter-mariadb adds a useTextProtocol option to toggle between text and binary protocols

Bug fixes

Prisma Client

• #29382: Disabled caching of createMany queries to avoid cache bloat and potential Node.js crashes in bulk operations
• #28724: Made NowGenerator lazy to avoid synchronous new Date() calls, fixing Next.js dynamic usage errors in cached components
• #29346: Fixed missing export of Get GroupByPayload type in the new prisma-client generator

CLI

• #29377: Added streaming parsing with automatic fallback for very large Prisma schemas that can hit V8 string limits

Driver Adapters

• #29390: Relaxed the @types/pg version constraint to ^8.16.0
• #29307: Corrected ColumnNotFound error handling so column names are extracted from both quoted and unquoted PostgreSQL messages
• #29392: Disabled mariadb statement caching by default to address a reported leak

Prisma Studio

Prisma Studio keeps improving in v7.6.0 with several highly requested features.

Dark mode

Dark mode is back in Prisma Studio.

Copy as Markdown

You can now copy one or more rows as either CSV or Markdown.

Multi-cell editing

It is now possible to edit multiple cells while inspecting your database. If you make changes, Studio will prompt you to either save or discard them.

Back relations

Prisma Studio now links to related records when your data references another table, making it easier to inspect relationships and move between connected data.

Generative SQL with AI

Instead of manually writing SQL, you can now use natural language and AI in Studio to generate the SQL statements you need when inspecting your database.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

Original source

Prisma ORM v7.5.0 adds support for nested transaction rollback behavior for SQL databases through savepoints.

This lets Prisma track transaction ID and nesting depth so it can reuse an existing open transaction in the underlying engine. It also enables using $transaction from an interactive transaction client while making sure inner nested transactions are rolled back when the outer transaction fails.

• #21678: Added support for nested transaction rollbacks via savepoints

Bug fixes

Driver Adapters

• #29285: adapter-mariadb now uses the binary MySQL protocol to fix lossy number conversions
• #29277: Made @types/pg a direct dependency of adapter-pg for a better TypeScript experience

Prisma Client

• #29286: Resolved Prisma.DbNull serializing as an empty object in some bundled environments like Next.js
• #29274: Fixed DateTime fields returning Invalid Date with unixepoch-ms timestamps in some cases
• #29327: Fixed a cursor-based pagination issue with @db.Date columns

Schema Engine

• #5790, #5795: Preserve manual partial indexes when the partialIndexes preview feature is disabled
• #5788: Improve partial index predicate comparison for quoted vs unquoted identifiers
• #5792: Exclude partial unique indexes from DMMF uniqueFields and uniqueIndexes

Studio

Prisma Studio continues to gain features in v7.5.0 based on feedback since the Prisma ORM v7 launch.

Multi-cell selection and full table search

You can now select multiple cells while viewing your database, and you can search across a table for specific values in addition to finding a specific table.

More intuitive filtering

Filtering is now easier to use and includes support for raw SQL filters. In Prisma Console, AI-generated filters are also available.

Cmd+K command palette

Studio now includes a Cmd+K command palette so you can perform most actions from the keyboard.

Run raw SQL queries

There is now a dedicated SQL tab in the sidebar that lets you run raw SQL queries directly against your data.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

Original source

Prisma ORM v7.4.2 is a patch release focused on bug fixes and quality improvements across Prisma Client, driver adapters, and the Schema Engine.

Fixes

Prisma Client

• #29243: Fix a case-insensitive IN and NOT IN filter regression
• #29262: Fix a query plan mutation issue that resulted in broken cursor queries
• prisma-engines#5784: Fix an array parameter wrapping issue in push operations
• #29268: Fix Uint8Array serialization in nested JSON fields
• #29251: Fix an issue with MySQL joins that relied on non-strict equality

Driver Adapters

• #29238: @prisma/adapter-mariadb now checks for a binary collation when detecting text columns
• #29246: Correct relationJoins compatibility checks for MariaDB 8.x versions

Schema Engine

• prisma-engines#5780: Fix partial index predicate comparison on PostgreSQL and MSSQL

Huge thanks to our community

Many of the fixes in this release were contributed by our amazing community members. We are grateful for your continued support and contributions that help make Prisma better for everyone.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

Original source