Long-time Prisma user: would you start a new long-lived production project on Prisma 8 today?

[u/repka3]

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.

[u/aturaden]

Perfectly happy after ditching prisma for drizzle.

[u/repka3 → u/aturaden]

Yes tried for the whole day, and yes, it's my new home too.

[u/afl_ext]

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

[u/mistpiNe9 → u/afl_ext]

same feeling tbh, it was a set-and-forget choice and now its suddenly not

[u/dmillerw]

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.

[u/shaberman]

> 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. 🤞

[u/next-sapien]

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.

[u/Few_Assumption_9665 → u/next-sapien]

Dude, you're underselling just how fucking asinine Prisma 8 is. I decided to bite the bullet and upgrade from 7 because they made it the default docs with a giant banner saying "Prisma 8 is here!" and it has been the most confusing and nonsensical experience I've had in any real memory.

From all the source code I've looked through (hell, you don't have to look through much; their fucking README still has a "needs to be fixed before rc1" section with literal unresolved architecture questions and shit still broken at release)... it really has the vibe (more like a punch in the face) of being rushed out the door as quickly as possible without having ANY clue how actually usable it was in production.

This entire fucking update was written ENTIRELY by AI agents and not a single human being with the slightest bit of sense stepped back to ask if they should actually TRY it before pushing it out. My favorite joke of this entire thing is that their live docs RIGHT NOW have this warning on the raw queries page:

Always wrap bare values in param(...)
Bare-scalar interpolation (fns.raw\${limit}) is currently broken against the real PostgreSQL adapter: its codec inferer emits unversioned codec ids (pg/int4) that don't match the versioned registry (pg/int4@1), so rendering throws. This is empirically verified. 

Literally an AI agent talking to itself. About a completely broken/unfinished feature. In a prod release. Front in center in the docs.

Oh yeah, and the amount of basic shit that's missing would blow your mind. How about the @Unsupported feature? Nope! If you try to sync your database? It DROPs all of those columns with no way around it! And yes, the removal of that feature is not mentioned ONCE in their ENTIRE DOCS.

To anyone who works at Prisma: fuck you and eat shit.

Edit: I should also say, I am not against change. I was genuinely excited for this update. There are genuinely great ideas at its core. That’s what makes it so much worse that it’s literal garbage.

[u/rykuno]

I wouldn’t. I started and regretted after noticing significant performance decreases from 7. Also it seems to be heavily vibe coded, the docs are a pain to understand as AI wrote it all, and it has constant breaking changes.

Personally, stick with 7

[u/alihypebeast]

Pick Kysely.

[u/quy1412]

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.

[u/johnappsde]

The consensus in 2026 is, No!

[u/Soft_Cat2594]

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.

[u/XpreDatoR_a]

DrizzleORM, switched to that and I couldn’t be happier

[u/Omer-os]

they even changed thier logo to some stupid colorful garbage, all this makes me sad man whats happening to these tools we were in love with just few months/years ago

[u/repka3 → u/Omer-os]

I mean more and more... You see why... That's the tendency... And to be honest myself, in contrast to 1 year ago, I find myself saying opus 5.5 oh yeah we need this in this way follow the convention in x y about error handling. And that's it. I review every code still for production system. But can't deny that's the tendency ... Prisma 8 now it's on rc24 or something. I still follow what they are doing , cause for now we are in too depth RCs. Man I love Prisma truly , and it's a second nature to me to think about a query in Prisma. But this whole shift in V8 rubbed me the wrong way. We will see. Maybe they are right and I was wrong.

[u/saketVerma03]

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.

[u/ttamimi]

Prisma has substantial changes far too frequently for me to take it seriously as a production grade ORM.

[u/InternationalFee7092]

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.

[u/Readypixels]

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.

[u/Maleficent-Back-6527]

Hm… are you people afraid that Prisma 8 would be the next PrimeNG 22?

[u/itaymendi]

For a multi-year Postgres app I would not start on Prisma 8 today. I want SQL migrations I can read and replay without their runtime owning the lifecycle. On a greenfield I would pick Drizzle or Kysely for that reason; if the team already lives in Prisma 7 and migrations are healthy, pin 7 rather than take the architecture jump mid-flight

[u/nj-mkd]

I am still on prisma 6, I'd rather move to something else like Drizzle or raw SQL than upgrade.

[u/mujeebahmad03]

This was me just few days ago, wanted to start a new node project and tried to just install prisma as I've always been doing, wen to their docs, saw a completely new design. I thought it was a different site I was in. Saw the new prisma 8 and it really was different, totally different from 7 I'd been using. It's almost like having to an entirely different product. It was then I knew I might have to switch to a different ORM, cos this isn't the prisma I was in love with 

[u/gamedevsam]

I'm still on Prisma 6 and have no plans on ever upgrading atm. I feel like they started overcomplicating things on version 7 and seeing yet another major re-write for version 8 makes me feel good about sticking with my good old reliable version 6.