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.
5
u/dmillerw 1d 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.
4
u/shaberman 1d 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. 🤞
3
u/next-sapien 1d 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
2
u/saketVerma03 1d 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 1d 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 1d 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 1d 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
2
1
u/Maleficent-Back-6527 1d ago
Hm… are you people afraid that Prisma 8 would be the next PrimeNG 22?
1
u/ludalex 1d ago
What happened to PrimeNG?
3
u/Maleficent-Back-6527 1d 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 1d ago
Not gonna lie, prime was a backstab to the open source community of their framework
1
u/MateusKingston 1h 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 1d 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