Prisma1: Prisma 2

[schickling]

Overview

Read more about the Prisma 2 preview here: https://www.prisma.io/blog/announcing-prisma-2-zq1s745db8i5

RFCs

• Migrations: RFC / Discussion
• Datamodel: RFC / Discussion
• JavaScript/TypeScript Client API: RFC / Discussion
• Client generators: RFC / Discussion
• Unit of work: RFC / Discussion
• Go Client API RFC
• Engine/Connector Architecture
• Configuration
• Import/Export
• CLI
• Seeding
• SDK

Repositories

https://github.com/prisma/prisma2
https://github.com/prisma/prisma2-cli
https://github.com/prisma/photonjs
https://github.com/prisma/lift
https://github.com/prisma/prisma2-docs

[brillout]

This all sounds exciting :+1:. Any ETA for a Prisma 2 beta/alpha release?

[brillout]

Also, how does Primsa 2 relate to your Roadmap?

And, will the Rust rewrite / #3504 Prisma RAM usage be part of Prisma 2?

[edunomatseye]

Pls let me know when we can use prisma without using Docker. That would be the greatest update I would love to see.

[outerlook]

Hi! Will I have to do any changes to my Nexus-prisma integration?

[pantharshit00]

We have released the preview of Prisma 2.

Read the announcement post here: https://www.prisma.io/blog/announcing-prisma-2-zq1s745db8i5

We would love to hear your thoughts on this.

[mk0a1a]

Any ETA on Go client API?

[marcus-sa]

Any chance that there'll be a configuration for the CLI? Currently it just generates the Photon ORM in a @generated/* scope inside node_modules.
This won't work if you by any chance are using microservices or several servers in the same monorepo as the generated path can't be specified since they'll just override each other.
We really need custom configuration.
Let me know and I'll see what I can do about a PR.

[pantharshit00]

@marcus-sa

You can configure an output property in the generator block now.

generator photon {
    provider = "photonjs"
    output = "./generated/photon"
}

[ntziolis]

One of the top reasons to use prisma is ability to easily leverage subscriptions from the DB layer without having to worry about it. Since you are moving the prisma engine side by side with the app:

How are subscriptions handled in a multi instances scenario?

• Subscription open for inserts of TypeA on Instance 1
• Record inserted for TypeA on Instance 2

How will Instance 1 know about the insert? Is there a way to "link" the prisma engines across instances?

[pantharshit00]

@ntziolis

Right now Prisma 2 doesn't ship with a subscriptions solutions yet. We have a plan for an events engine which will be bin-log based rather than using the data which we have in the Prisma 2 which will be more sustainable. I can't give you an ETA on that as we are willing to spend time on designing the engine carefully.

[ntziolis]

@pantharshit00 Thank you for this info. Please keep us informed on progress here as without DB subscriptions we do not have much use for prisma tbh.

Also I would recommend calling this out (prominently) in the Prisma 2 blog post as there are probably plenty of folks who get very excited but are in the same boat as we are where not having subscriptions is a hard blocker to adopt prisma 2.

[hoffnung8493]

I am considering to use prisma in production, but not sure if I should use prisma 1 or prisma 2. In terms of stability it makes sense to use prisma 1, but because of the docker part, I would rather use prisma 2. I only need stable graphql query and mutation to work(no subscription for now). Can you guys share some advice on this issue?

[bmcilw1]

@hoffnung8493 I am in the same boat trying the decide the same. I am designing the backend for a startup. I love the ease of development with Prisma. However, it must be deployed to production, and when it does it needs to work. However, our use case is overall very simple and minimal from a load perspective.

Background

• Our app will not be ready for full production deployment for 2-3 months, so both projects have about that long to progress.
• We've used a serverless GraphQL backend to maximize flexibility and minimize boilerplate on our front end while preparing us for scale.
• The nature of our data is that it is highly partitionable per user. It can fit in a relational database, but the more ideal database for it is certainly Mongo due to the partionability and higher availability. Because of Prisma's Import/Export functionality, we may be able to initially deploy to a relational DB until Mongo support comes to v2, at which point, we'd export our data and import it into Mongo.
• Expected usage of the app would be intermittent. Most users would only need to use the app for 1-6 weeks and not again for as much as a decade. Because of this, metrics like max concurrent users as well as the load-per-user metrics would be minimal. It shouldn't be hard to scale to 1,000s and 10,000s of users as only perhaps 10% of that would be actively accessing data at a given time.
• Currently, there is no need for real-time data flow via subscriptions.

Would Prisma 2 (v2) likely be just good enough to handle this simple workflow? If not, is Prisma 1 (v1) able to handle this stably and in prod? If we must use v1, is there a way we can make a Prisma server capable of handling a maximum of 100s of concurrent users that could be done in a day or 2? Is there any way that doesn't require a Docker/Kubernetes distributed DevOps expert or me becoming one in order to get this thing deployed?

Thoughts?

---

Edit - I currently have two Prisma servers working locally for development, one with an embedded local Mongo container and another connecting to the dev MongoDB instance (on Atlas).

Edit 2 - Due to the huge memory consumption needed by v1, we might be forced to take our chances with v2 or failing that revert to Mongoose until we scale enough to not have to care about the high cost to run the server 😞.

[pantharshit00]

Hi all,

I am going to lock this issue now as the feedback is getting fragmented among repositories for us. Please open a new issue here if you have more questions. I am going to answer the last remaining questions here:

---

Should I use Prisma 1 or Prisma 2 in my new project?

Prisma 2 is not yet production-ready, it has a number of severe limitations that don't make it suitable for production uses and heavy loads.

You can track the progress of the release process on isprisma2ready.com. While it shouldn't be used for critical applications yet, Prisma 2 is definitely in a usable state. You can help us accelerate the release process by using it and sharing your feedback with us.

If you want to start using Prisma immediately in a critical application, the recommendation is to use Prisma 1 and migrate to Prisma 2 later. There will be detailled migration guides and tooling that help with the upgrade process. We're investing a lot into making the transition to Prisma 2 as smooth as possible!

I'm using Prisma 1, when should I upgrade to Prisma 2?

It is recommended to wait for the General Availability release of Prisma 2 (which will follow later this year) to upgrade your application to Prisma 2.

Will Prisma 1 still be maintained?

Yes, Prisma 1 will continue to be maintained. However, most Prisma engineering resources will go into the development of Prisma 2 (i.e. Photon and Lift).

There will be no new features developed for Prisma 1.

---

You can help us accelerate the release process by sharing your feedback. Please report any bugs, ask questions and lets us know your improvement ideas and wild wishes for Prisma 2! 🙏

If an open question hasn't addressed here, you can check out our FAQs or reach out to us personally.

[steebchen]

@mk0a1a For the Prisma 2 Go client, please see the tracking issue https://github.com/prisma/prisma2/issues/571 and the actual work at https://github.com/prisma/photongo.