This quarter, our focus is Prisma 7 entering LTS while we build Prisma Next in the open.

Prisma 7 remains our production product and our top priority for production workloads. If you’re shipping today, Prisma 7 is the recommended version of Prisma.

Prisma Next is the new foundation we’re building to unlock the next generation of features (and, when it’s ready for general use, Prisma Next becomes Prisma 8). But Prisma 7 isn’t going anywhere, this roadmap is about making Prisma 7 faster, more reliable, and more complete as an LTS release.

Top goals this quarter

---

1. Stability & Reliability: reduce regressions, strengthen test coverage, and improve confidence in releases
2. Performance: improve performance in real user workloads
3. Restore missing Prisma 6 functionality: finish filling gaps from the Prisma 7 transition (MongoDB excluded, see the note below)
4. Smoother upgrades: make moving to (and staying on) Prisma 7 simpler and safer

---

1) Stability & Reliability

Prisma 7 shipped a major internal rewrite and it’s already paying off, with that being said, LTS means we now optimize for predictability and low regression rate.

What we’re doing

• Re-establish regression coverage we lost during the Prisma 6 → 7 transition
  • We’re expanding coverage in the test harnesses that most reliably catch “works in prod but not in CI” class regressions
• Harden query parameterization coverage
  • We’ve seen several user reports tied to the recent parameterization work. This is exactly the kind of change where missing test coverage can hide real-world edge cases
  • We’re investing in targeted coverage so these issues are caught earlier and don’t regress quietly across releases
• Treat Prisma 6 → Prisma 7 behavior regressions as high priority
  • When something used to work and no longer does, our goal is to either fix it quickly or clearly document the new behavior with an upgrade-safe path

What you can do to help

• If you hit a regression: include a minimal reproduction alongside:
  • Prisma version(s) affected (last known good + first known bad)
  • Database + version
  • Runtime + deployment environment (see [Operating Contexts](Priorities & Operating Contexts #25843))

---

2) Performance

Prisma 7 now performs as well or better than Prisma 6, but there are cases where we believe performance can be further improved.

What we’re doing

• Investigate real-world usage reports
  • We’re prioritizing cases that are frequent, high-impact, and reproducible
• Focus on end-to-end performance
  • Not just raw query execution but also compile/plan time, cold starts, and the surrounding overhead that matters in serverless and modern production setups

What you can do to help

• If you have a slowdown: share a benchmark script or query pattern, plus:
  • dataset size / cardinality assumptions
  • indexes
  • whether it’s warm vs cold
  • deployment environment and Node version

---

3) Restoring missing functionality from Prisma 6 (SQL) and filling gaps in Prisma 7

Prisma 7 introduced major architectural changes. Some functionality from Prisma 6 didn’t make it into the initial Prisma 7 release, and some edge cases surfaced only after broad adoption

What we’re doing

• Close “Prisma 6 parity” gaps for SQL databases
  • We’re focusing on the gaps that affect production adoption and day-to-day workflows
• Fill the gaps from the Prisma 7 initial release
  • This includes correctness issues, missing behaviors, and compatibility problems that block upgrades

MongoDB note

Prisma 7 shipped without MongoDB support, and we’re making a clear call here:

• MongoDB support will come through Prisma Next, not Prisma 7
• The goal is not just “MongoDB support”, but a Mongo-native experience that reflects MongoDB’s strengths end-to-end

(We’ll share more MongoDB + Prisma Next updates as that work progresses)

---

4) Improve the upgrade / migration experience

LTS should feel boring in the best way: upgrades should be easy, safe, and unsurprising.

What we’re doing

• Make Prisma 7 upgrades clearer and safer
  • Better guidance around common pitfalls, compatibility gotchas, and “what changed” when users move from Prisma 6 → 7
• Reduce “upgrade tax”
  • Fewer sharp edges, clearer diagnostics, and fewer cases where you need to guess which subsystem is responsible for a failure

---

How we’re thinking about Prisma Next (and what it means for Prisma 7)

Prisma Next is where new capabilities will land first especially features that require a more composable, extensible foundation.

Prisma 7 is where we focus on:

• stability
• reliability
• performance
• closing gaps
• a predictable LTS lifecycle for production teams

If you want to follow Prisma Next work closely, we’re building it in the open:

• https://github.com/prisma/prisma-next

---

Community: how to influence priorities this quarter

We’ll weigh issues by:

1. Criticality (data integrity, correctness, security)
2. Impact (how many users + how often)
3. Reproducibility (minimal repros unblock fixes fastest)
4. Operating context alignment (see [Operating Contexts](Priorities & Operating Contexts #25843))

The most helpful signals:

• 👍 reactions on issues that match your pain
• minimal reproductions
• clear “last known good version” comparisons

---

Closing

Prisma 7 is our production ORM and remains our priority. This quarter is about making Prisma 7 an excellent LTS release: solid, fast, and trustworthy, while Prisma Next is built in parallel to enable the next generation of Prisma features.

If you have regressions, performance gaps, or “Prisma 6 → 7 parity” issues that are blocking upgrades, link them in the comments and we will be actively triaging and prioritizing those reports.