Announcing Prisma 7

Designed for the future

In December 2024, we published our vision for the future of Prisma ORM along with the steps we planned to take to achieve it. This was not just a set of ideas. It was a clear commitment to how we want Prisma ORM to evolve and how we intend to support the community along the way.

We also launched our own managed Postgres offering, Prisma Postgres. Built with simplicity and performance in mind, we wanted to provide an easy-to-adopt database that would bring all of the developer experience you know and love from Prisma ORM.

With the ORM roadmap and Prisma Postgres launched, we had a solid foundation for how to build the next version of each tool. The response to both of these products has been stellar. We see significant growth in the ORM market share and usage, and Prisma Postgres' hobby and commercial adoption has been spectacular.

Moving away from Rust

When we launched 6.0.0, we promised better performance, more flexibility, and better type-safety. We knew there was work to be done, and to get there, we needed to make some drastic changes.

We announced we were migrating the Prisma Client away from Rust and rebuilding it in TypeScript. This might have seemed like a strange move to some, as Rust’s main premise is that it is fast and performant. But that is only half the story in our case.

A side effect of the client being built in Rust is that we were limiting who can contribute to the ORM. If you didn’t have strong Rust experience, it was far more difficult to make any meaningful contributions. On the technical side, the communication layer between Rust and the JavaScript runtime is much slower than doing things in plain JavaScript, plus it creates additional dependencies on the runtime. Our friends at Deno shared this sentiment:

Moving to a Rust-free client really set the stage for a faster client runtime, a smaller footprint, and simpler deployment story. You no longer needed to worry about runtime-specific quirks or infrastructure providers, like Cloudflare Workers, limiting the size of the deployed application. We continued on the path and kept iterating on what would become the Rust-free Prisma Client. The results?

• 90% smaller bundle output
• 3x faster query execution
• Significantly lower CPU and memory utilization
• Simpler deployments for Vercel Edge and Cloudflare Workers

And we have the benchmarks to prove it. The best part? You don’t need to rework your entire application to benefit from it. The changes required to switch are super simple.

We’ve been talking to dozens of users from the community, as well as close friends like Kent C. Dodds, and the feedback has been very positive:

Generated code out of node_modules and a new config file

Additionally, we've taken the feedback regarding how we handle generated artifacts and made it better and more universally compatible. We covered this some time ago, but we historically generated the client in your project's node_modules. At the time, this made sense as we wanted to make working with the generated client feel like any other library. But as time has progressed, we've found that this impacts developer workflows significantly. If the client needs to be updated, any app-specific processes need to be stopped first before regenerating the types. Instead, we default to generating the types and Prisma Client in your project source code, so your existing dev and build tools see it as part of your app. Now if you make changes to your models and run prisma generate, tools and file watchers can react to these changes and keep your dev workflow running. Your whole setup just becomes a part of your project, not something that is obscured in node_modules.

We also added support for dynamic project configuration with the new Prisma config file. The Prisma config file exists to separate your data and how Prisma interacts with that data. Previously, this project configuration was spread across your Prisma schema or package.json. The Prisma config file solves this by being the one location where you can define schema locations, seed scripts, or your database URL. And with it being a JavaScript or TypeScript file, the configuration can be dynamically set with tools like dotenv. This gives developers control over what gets set in their project config, and brings this part of the experience up to the standards you should expect from modern developer tools.

Faster and fewer types

But this wasn’t all we focused on. One of Prisma ORM’s main benefits is type-safety. This means making sure we not only provide the correct types, but do so in a way that is fast and efficient. To improve this, we collaborated with David Blass, the creator of ArkType, to evaluate how well we were generating our types. The results are well worth a read, but the highlights include:

• Prisma requires ~98% fewer types to evaluate a schema
• Prisma requires ~45% fewer types for query evaluation
• Prisma is 70% faster when performing a full type check

Compared to other ORMs in the ecosystem, our generated types were not only faster to evaluate, but required fewer types in order for TypeScript to provide useful information to the user. Why does this matter? Because developers can build their applications with confidence knowing that the type-safety we offer is not only fast, but has less overhead.

Prisma Postgres for all

But Prisma is more than just an ORM. Our managed Postgres database was built to give developers the thing they need when they get started with Prisma ORM… a database. We built Prisma Postgres with bare-metal infrastructure powered by unikernel microVMs. All that means is that things are fast, and stay fast. But we kept the developer experience in mind, handling the complex parts so you don’t have to manage them yourself. Instead of having to worry about provisioning or resource configuration, we manage all that for you, and integrate natively with Prisma ORM. The same great DX you're used to from the ORM, also for your database.

Getting started with Prisma Postgres is as simple as running a single command from your terminal:

You’ll get a database provisioned for you, and a link to claim it once you’re ready. For those using AI agents in their developer workflows, we provide a dedicated API and MCP server that can be used to create and manage databases as they are needed.

Prisma Postgres hasn’t stopped there though. We have now adopted the standard Postgres connection protocol so that any tool in the wider ecosystem can talk to your database. This means tools like Cloudflare Hyperdrive, TablePlus, Retool, or even other ORMs can all be used with Prisma Postgres.

All of this is possible because Prisma Postgres is just standard Postgres, but built to provide the best Postgres experience.

What else is changing

There’s a lot in this release that we would love to talk about, but then this post would be much longer. We're already grateful you read this far! We’ve spent countless hours working through our backlog of issues and feature requests to address some of the top requested ones, like mapped enums, updating the minimum version of Node and TypeScript required for projects, as well as a brand new version of Prisma Studio via npx prisma studio. You can find everything that’s in this release in our changelog, and we have a migrations guide available as well.

Thank you

This is not just another version release for us. It's the foundation of what comes next for Prisma ORM and Prisma Postgres. We want the tools we've built to provide the best possible experience, so developers can focus on building and shipping amazing applications. So thank you to our incredible community and a special thank you to everyone who has provided feedback during our pre-release process. And to everyone giving Prisma 7 a shot now: please tell us what you think!

For migration guides and additional resources, please check out the links below. Be sure to follow us on X/Twitter, and join our Discord to get the latest updates as they’re released.

• Prisma ORM Migration Guide
• Prisma ORM Changelog
• Prisma Postgres
• Prisma ORM
• Prisma ORM repo on GitHub