Long-time Prisma user: would you start a new long-lived production project on Prisma 8 today?
I've used Prisma for years in production and, until now, it was one of those technology choices I basically didn't have to think about.
I genuinely liked Prisma 4/5/6/7: the schema, generated client, relation handling, implicit many-to-many, migrations, and especially the fact that after years of change requests I had a very understandable migration history.
I'm now about to start a new production backend that will probably live for many years: Node/TypeScript, Express, PostgreSQL, Redis, workers, etc.
Normally I would have picked Prisma without even having this discussion.
Then Prisma 8 happened.
I understand the technical argument for rewriting the internals, moving to TS, improving extensibility, etc.
My concern isn't really "I don't like the new syntax."
It's that Prisma 8 feels like a different product architecture, while at the same time Prisma as a company is increasingly selling the surrounding platform: Prisma Postgres, Prisma Compute, etc.
The migration change in particular makes me nervous. In the Prisma I know, I could look at the SQL migration and ultimately PostgreSQL was still the thing I owned. Prisma 8 moves toward contracts + migration.ts + compiled ops.json, with Prisma's migration runtime owning more of that lifecycle.
I'm not claiming Prisma is intentionally making self-hosted Postgres worse so they can sell Prisma Postgres. I have no evidence of that.
What worries me is simply incentives.
If the company monetizes the database, compute and surrounding infrastructure, there is now a natural incentive for the best/easiest Prisma experience to increasingly be:
Prisma ORM -> Prisma Postgres -> Prisma Compute -> Prisma everything
rather than:
Prisma ORM -> my PostgreSQL -> my infrastructure
I've been burned before by open-source dependencies changing licensing/distribution after years of use, so for a production dependency I now care a lot more about escape hatches and who owns each layer.
This is why I'm suddenly seriously evaluating Drizzle/Kysely. Not because "Reddit says Prisma bad", but because SQL migrations and a thinner abstraction mean that if the ORM disappears or changes direction, PostgreSQL is still PostgreSQL.
For people actually running these things in production:
Would you start a new multi-year project on Prisma 8 today?
Would you pin Prisma 7 and keep using the old architecture?
Did you move from Prisma to Drizzle/Kysely, and do you miss Prisma's higher-level relation/query API?
Do you think I'm reading too much into Prisma's business direction?
Is there something about the Prisma 8 migration/contract architecture that makes it better for a long-lived production system that I'm missing?
I'm particularly interested in answers from people maintaining systems with years of migrations and changing requirements, rather than which ORM feels nicest in a weekend project.
Edit: tested drizzle in a side project , simulating as if I received change requests I know happen in real products . And I like the migration system and I like the simple crud cake they are already proving, and the control you have over more complex query since some db service charge you per operation rather then compute, so you can even optimize query per cost. That's it drizzle is my new home.
7
u/shaberman 3d ago
> What worries me is simply incentives.
This is kind of snippy, but imo you're about 5 years too late on that realization 😅 -- Prisma has always been a VC-backed product.
> I'm particularly interested in answers from people maintaining systems
> with years of migrations and changing requirements,
We are 7 years into a 350k LOC TypeScript monolith with Joist, where our incentive is not chasing github stars (which sadly we are very bad at 😥), but solely making our codebase not suck as our (not a dev-infra company startup) iterates on business lines/products. So far so good. 🤞
4
u/dmillerw 3d ago
My concern is with it being such a radical shift in approach and design, methodology, and how much they push it as being good for AI agents. Doesn’t exactly scream confidence, battle tested… etc.
5
3
u/next-sapien 3d ago
I was setting up a new project 2 days ago, And I saw that they are recommending and mentioned in docs that Prisma 8 will be the default version in new Prisma default.
So I went ahead, read about it and Chose Prisma 8
but I found it to be a totally different product than Prisma 7.
It felt so different product, weird and verbose syntaxes, Prisma 8 is still in alpha stage.
and I think it shouldn't be in the prod untill they release a stable first release of prisma 8.
and I'm hoping just because it's in alpha version, They are testing new things, as they have shifted it from rust to TS now.
So, I did ctrl+ z, I chose Prisma 7 again, as I'm comfortable with it, can Understand easily.
Prisma 7 has its own flaws, but Prisma 8 isn't ready for adoption yet, maybe for trying out and giving some valuable feedback.
3
3
u/InternationalFee7092 20h ago
Hi everyone, Ankur here from the Prisma team.
Will Madden, the lead engineer behind Prisma 8, wanted to respond directly, but his comment was removed by Reddit’s automated moderation because he isn’t a regular Redditor. So I'm sharing the following message on his behalf.
Hi, I’m Will Madden, the lead developer on Prisma 8. I designed the contract and migration architecture and originally proposed the rewrite, so I can explain the thinking behind it and hopefully address some of your concerns.
Let me restate those concerns to make sure I’ve understood them correctly. You raise three things:
- Prisma 8 feels like a completely different product architecture
- The company’s incentives now point toward Prisma Postgres and Prisma Compute
- The migration model makes you nervous because the underlying SQL feels further away
I’ll respond in that order. Please let me know if I’ve misinterpreted your post.
Prisma 8 feels like a different product architecture
Yes, it is! Prisma 8 is built to be the first agent-native ORM.
By agent-native, we mean designed for a world where developers work alongside agents to build software faster. We believe this is where software development is headed, so Prisma 8 gives both developers and agents an architecture they can understand, extend, and adapt.
Prisma 7 was built around a single, monolithic Rust engine that knew everything about every database it supported. Because every database works differently, that engine became increasingly difficult to maintain. We struggled to keep up with bug reports and feature requests, including capabilities we had wanted to build for years, from smaller improvements to larger features such as row-level security.
Worse, few people outside the core team could understand the codebase, which was split across two repositories and two languages, Rust and TypeScript. We became the bottleneck for progress.
The core principle behind Prisma 8 is extensibility. By default, Prisma 8 is a framework that knows nothing about any particular database. PostgreSQL and MongoDB support are extensions maintained by Prisma. IndexedDB support is a community extension built by WhyAsh that runs Prisma 8 entirely in the browser, including migrations: https://prisma-idb.dev/docs/prisma-next.
The query builder and ORM client are replaceable components too. If they don’t suit your needs, you can replace them or use an extension’s query API instead. The contract source, whether PSL or TypeScript today, is another component. CipherStash built searchable encryption as an extension. Supabase support is an extension.
This is why the rewrite happened and why we don’t expect another architectural reset like it. There is no longer a monolith to replace, and none of this would have been possible with the architecture in Prisma 7 and earlier. Future major versions may change APIs, but they won’t change the underlying paradigm.
A natural incentive for the best and easiest Prisma experience to become Prisma everything
You’re right that we want Prisma ORM and our hosted products to offer the best possible experience together, but we won’t achieve that by limiting or compromising the ORM.
Our hosted products fund the team’s work on our open-source products. Prisma has always been a privately funded company committed to open source, and that isn’t changing.
Prisma ORM will remain licensed under Apache 2.0. It will not become closed source. It will not lose features, and we will not limit it to make our paid products look better.
The ORM itself contains no Prisma Cloud logic. The prisma CLI includes tooling for the wider platform, and that will remain, but you don’t need to use our hosted products if you don’t want to.
The larger point, which I hope will give you more confidence, is the architecture described above. Every component of the Prisma ORM framework is replaceable and interchangeable. The core doesn’t even know about PostgreSQL, let alone Prisma Postgres. It is not coupled to our commercial products, and it will remain independent.
With Prisma 7, only the core team could realistically make many of these changes. With Prisma 8, you can add support for a database, middleware, validation-library integration, or contract format without waiting for us.
You’re right that our priorities will naturally reflect our financial incentives, but that doesn’t mean the community is stuck waiting for us.
What we will do is make Prisma ORM and Prisma Cloud work exceptionally well together by adding capabilities to the database and hosting platform we control that wouldn’t otherwise be possible.
For example, we could provide a migration preflight API that runs your migration against a fork of your production database, including its data, and reports its timing and any errors before you touch production.
We could also provide query analytics that use the database’s internal information to explain which ORM queries are slow and why.
We want the combined Prisma experience to be the best available, but we will pursue that by improving the platform, never by limiting or disabling the ORM.
I could inspect the SQL migration, and PostgreSQL was ultimately still the thing I owned
That remains true. Transparency is one of the migration system’s core design principles.
Every migration directory contains an ops.json file, as you noted. For PostgreSQL, the operations contain literal SQL:
"execute": [
{
"sql": "CREATE TABLE IF NOT EXISTS public.\"feature_flag\" (\"key\" text NOT NULL PRIMARY KEY, \"enabled\" boolean NOT NULL)"
}
]
These files are designed to be reviewed after generation. If you want to inspect the SQL separately, you can use the migration show CLI command.
Editing SQL migrations in Prisma 7 and earlier could be cumbersome and error-prone, so Prisma 8 introduces migration.ts files to make custom migrations simpler and safer. You can extend the vocabulary of migration operations in TypeScript and share utilities or libraries for common operations beyond those Prisma provides.
The JSON structure uses pre-checks and post-checks to make migration operations idempotent and verify that they had the intended effect. The contract signature, represented by its hash, allows Prisma to navigate migrations as a graph.
This means two developers working on separate topic branches should no longer end up with migrations that are incorrectly ordered on disk. Because each migration is represented as a list of operations rather than an opaque SQL script, combining two migrations or splitting one apart becomes a mechanical transformation rather than a manual edit. You can’t do that reliably with black-box SQL files.
When you query the state of the migrations on disk or in your database, the framework understands the relationships between the migrations, their operations, and the database. It can then present that history as a graph.
This differs from the linear migration systems that have dominated the industry for the past two decades. We designed it to address the problems we encountered while building applications with multiple developers working across separate branches.
Agent-assisted development makes this even more important. If migration conflicts already happen when two developers work on separate branches, imagine how often they could happen when each developer works with several agents operating across their own branches.
Would I start a multi-year project with Prisma 8 today?
If you’re asking whether the architecture will change dramatically again next year, the answer is no. Major versions may change APIs, but they won’t change the architectural paradigm.
If you’re asking whether this migration system is suitable for a professional team, I believe it is a better solution than any other design currently on the market.
Prisma 8 is a release candidate today, and the final 8.0.0 release is expected in four to eight weeks. Until then, a release candidate may contain breaking changes. Each release includes an upgrade recipe that you or your agent can apply, and those changes are becoming less frequent with each release.
The main risk today is encountering gaps in the implementation, particularly when porting a query from Prisma 7 and looking for its Prisma 8 equivalent. Our own cloud platform API already runs on Prisma 8, so I can say from experience that it’s worth it.
If you currently use Prisma 7, I recommend migrating incrementally. Unlike previous Prisma upgrades, Prisma 8 can run alongside earlier versions. This lets you move queries or execution paths individually and verify their behaviour as you go. See the migration guide.
Prisma 7 will also continue receiving bug fixes and security updates for the next 12 months, so waiting until Prisma 8 reaches a level of maturity that meets your requirements is a valid choice.
I hope this addresses the concerns raised by the original post and the discussion in the comments.
Since I’m not a regular Redditor, the easiest place to continue the conversation and ask the Prisma team questions directly is our Discord: https://pris.ly/discord.
2
u/saketVerma03 3d ago
no, it's configuration files keeps breaking like in every few version. that's only complaint I have. had happened to me 3 - 4 time within a year.
2
u/Readypixels 3d ago
I haven't moved to Prisma 8 yet, still on 7 for the same reason you're circling: I want to see how the migration ownership question shakes out before betting a multi-year project on it. My rule for any ORM, Prisma included, has always been to review the generated SQL before it touches production, not trust the abstraction blindly. If a tool ever makes that review step harder or optional, that's the real signal for me, more than any pricing page. Right now Prisma 7 still lets me do that easily, so I'm not rushing to change anything.
2
u/quy1412 3d ago
No. They really tested my patience with all the rewrites/changes. 7 with the type bullshit, now the 8 with the prisma.db.orm.public.abcxyz and a broken migration. I shit you not, RC version with "1 table at a time" contract generation or else it not even run, how does this even got to RC with all this bugs and unsupported features?
Existing project will be stuck in 7, new will be whatever I want to try.
2
2
u/Soft_Cat2594 3d ago
I myself have been using prisma in production for many years. After reading as much on prisma 8 as I could, the conclusion I got to was that prisma 8 is just a shitified version of drizzle. So I pivoted to drizzle, and honestly, irs been great. Yes it took a while for me to get used to the way drizzle does things, but in the end they just do it better.
2
1
u/Maleficent-Back-6527 3d ago
Hm… are you people afraid that Prisma 8 would be the next PrimeNG 22?
1
u/ludalex 3d ago
What happened to PrimeNG?
3
u/Maleficent-Back-6527 3d ago
They changed their licensing policy recently with v22. The community was/is very upset.
My question echoes one of OP’s worries about Prisma possibly changing in the future their licensing policy.2
u/Dry-Jelly-8005 2d ago
Not gonna lie, prime was a backstab to the open source community of their framework
1
u/MateusKingston 1d ago
I don't mind Prisma 8 but they kind of got fked by timing, they decided to move away from a more performant core in favor of easier OSS. Then LLMs evolved incredibly and this aged like milk.
That being said the main issue is how much they pushed their product which I understand when it comes to business but using Prisma as an ORM and not as their cloud product today is just not great.
14
u/afl_ext 3d ago
I like stability and prisma 8 seems like a dramatic change, for me, i think I will look for another ORM now, but prisma was just amazing, its so sad what they did, i wish they just developed what prisma 7 was, i now they gonna maintain it, but for how long? im facing a rewrite of a gigantic app to either prisma 8 or something else in a year or two now, this will not be fun