(EDIT: OUTDATED!) P̶r̶i̶s̶m̶a̶ ̶C̶l̶i̶e̶n̶t̶ ̶G̶o̶ ̶w̶i̶l̶l̶ ̶n̶o̶t̶ ̶b̶e̶ ̶O̶f̶f̶i̶c̶i̶a̶l̶l̶y̶ ̶M̶a̶i̶n̶t̶a̶i̶n̶e̶d̶ ̶a̶n̶y̶ ̶m̶o̶r̶e̶

[matthewmueller]

EDIT: THIS ISSUE IS OUTDATED!

PLEASE SEE --> Prisma Client Go: Resurrection <-- FOR AN UP-TO-DATE OVERVIEW.

---

original issue (Dec 21, 2021):

Hey everyone,

After a lot of consideration, we've decided to stop the development on the Go Client. The Go client has unfortunately not seen the growth we were hoping for. To understand this decision a bit better, I'm sharing a chart that shows the number of installs over the last 12 months:

As you can see, there's been stable adoption, but not much growth.

This doesn't mean that the Go client isn't useful or that the Go Client is a bad idea. We've just learned that the Go Client won't grow by itself. We would need to invest more resources to reach the kind of adoption we would need to sustain the development. Given our priorities for the next year, the Go Client just didn't make the cut.

I'd like to take a moment to thank @steebchen for his work on the Go client for the last 2 years. He's been working tirelessly on answering questions, fixing bugs and implementing the features you've been asking for.

I've added an FAQ below, but I'll leave this thread open to answer any additional questions you might have. We're sorry for the inconvenience this may cause you.

FAQ

When does the development stop?

We are stopping the development of the Go Client immediately.

Will critical issues and bugs be fixed?

Unfortunately, we won’t have any resources to fix any outstanding or upcoming issues with the Go Client. Community members are more than welcome to fork the repo and continue the development of the Go Client on their own (as a reference, you can look at the Python Client which has been developed from scratch by a community member as well). If anyone is interested in that, we are happy to help with the first steps in adopting and distributing.

What is going to happen to the repo?

This repository will remain in place as a point of reference.

Will you change your mind in the future and pick up the development again?

Possibly. As we grow larger and reach more enterprises, the Go ecosystem is likely to become more relevant again. The type of Go Client we offer then may look different than the current one though.

[hi019]

This is super unfortunate, you guys made an amazing ORM :(. Thanks @steebchen for all your work maintaining the client, especially the speedy issue responses and fixes

[gjermundgaraba]

That is unfortunate. But isn't it also a bit premature to make any conclusions on adoption with something that has only been in "Early Access"? The note on those kinds of features are "We don't recommend using Early Access features or products in production."

So for instance I have personally followed the development and wanted to use this when it was ready, but I don't have time to play with it until it is more ready.

I of course respect your decision on this, but I find the argument a bit weak. I also would not expect to see a lot of growth for something that you can't use for anything real :)

[yar2001]

Oh No... I've been struggling for a while whether I should migrate to Prima (from gorm).

Prima really accords with my ideal ORM. None of the other ORM in Go (as I know) can construct Where clauses with auto completion and provide consistent development experience.

The reason that Prisma haven't seen the growth is probably nobody knows it. If I am a beginner, I will Google it to compare all the ORM. And no results in the first page (for my locale, key word: go mysql orm and go postgres orm).

I found Prima because I am using Nest.js and it is in the Nest.js document. I haven't started using it yet (because I use MongoDB for node) but it impressed me a lot. When I use Go for MySQL and Postgres, I was disappointed to find that the popular ORM in Go failed to provide a good experience(compared with TypeScript, the latter provide a really excellent type system). So I wonder will some library provide SQL generator just like Prima, and I found that Prima offers it itself! However, when I hesitated whether to migrate to Prima, I found this announcement.

Anyway, what you guys are doing is awesome, and hopefully more people will get a chance to use it one day.

[s-takehana]

[Southclaws]

This is really unfortunate to hear, thanks @steebchen for maintaining it and answering all my questions over the years!

I literally just migrated my company's database ops to Prisma, and while Prisma itself is still useful as a schema and migration tool we'll have to consider an alternative for talking to the DB (raw SQL strings are just painful)

Which sucks a lot because I've been writing Go for many years and none of the database connectors come anywhere close to Prisma - they're mostly string based and not type safe.

I may consider helping maintain this as it's so useful and I use it in 3 production applications (2 of which are businesses) - here are a couple of alternatives off the top of my head:

• https://entgo.io/
• https://sqlc.dev/

I am also surprised at the move, but I think this tool really needs more fanfare in the Go community. I attend the London Gophers meetup and this would be a fantastic platform to tell Go engineers about Prisma. I really hope you focus on Go again in future as it's a huge language in the enterprise space and in my experience, often the go-to tool for migrating legacy systems into new world tech - prisma db pull is vital for these legacy migrations.

Anyway, thanks for your work! I will poke around the codebase and learn it a bit more.

[robin-macpherson]

This is really unfortunate and is a bit of a painful reminder of the abandoned Nexus Framework project and the abandoned nexus-plugin-prisma package (that one with a new project to rebuild it, but with zero support of the old one in the meantime and putting people who were using it in production in a horrible position for an incredibly long time now). Both of these impacted us heavily.

I'm not sure if this is being unfair to Prisma or not and I apologise if it is indeed unfair, but it's starting to feel like there is a bit of a grave yard that we keep arriving at time and time again...

In any case, echoing other comments, thanks so much @steebchen for all of your work on this – I can't imagine how you must be feeling with this news.

[AmreeshTyagi]

Thanks @steebchen for your great work. It's a bad news for those who are migrating their tech ecosystem from nodejs-prisma to golang-prisma or planning golang with prisma like me. :(

I was about to move grpc micro-services from nest.js to golang with prisma as ORM. But now, I will refrain myself.

There is lot of ORMs which support multiple database, but I hardly found which can support multiple programming language support as well. Prisma is one of them. <3

As per my own observation, I see most of 5-10 years XP nodejs developers/engineers are moving to golang, who are seeking for such type of ORM which can bridge a gap between nodejs-golang when working with databases. Hope this client will be in healthy state with community support.

[Southclaws]

From what I've heard from Go developers I know, the reason this project wasn't picked up was because it was branded as "experimental" so you can't really expect real usage at real live company software to use an experimental package.

But from my ~2 years of using it in 4 projects (2 of which were for business - yes, I'm a risk taker!) it didn't seem that unstable and I feel like you could have made the pitch a little less scary to increase usage.

Another thing is just the age old blog posts and videos/screencasts to get people excited - the TypeScript side of Prisma has loads of great marketing efforts. If the same were to be done for Go, believe me it would be huge because Go's database landscape is really really lacking compared to more mature languages like Java, C#, Ruby, etc.

---

Here's my question to Prisma:

What would it take, numbers wise, to put development effort into this project again? A handful of paying customers using Go? More open source usage? I was seriously considering paying for Prisma cloud for a couple of my products but they're all written in Go.

[paulm17]

Just want to come at this from another angle.

I tried picking this up myself and kept running into issues. So went back with plain old database/sql.

I'm practically on the verge of dropping Prisma entirely. Don't get me wrong, I love the typescript version. But with the last 5 or 6 releases being focused on Mongodb, which frankly is not taken seriously because Postgres with a jsonb column is 100x better. It's signalling to many, that the desire to be cross compatible rather than shoring up important issues that the community (loudly) has been asking for, is more preferable.

With a barrage of issues that are open, not only affecting me and (probably) other individuals on the same boat after a full year. My excitement is starting to wane. I'm well past the point where basic features will suffice and wanting more complex functionality just isn't there, well is frankly disappointing.

Upon hearing these news, its saddening. You don't develop a library in the hopes that it will be popular. With Go, you develop it because you want to be in the Enterprise space. And that's what you want to signal.

[TheBeachMaster]

This is horrible, and I just feel like someone has just pulled the rug under my feet... I have 3 production apps running on this client.

Now I have to spend days migrating 10'000s of LOCs to ent.

If you label a project as Early Access clearly people would hesitate adoption(a few of us took risks to run it on prod so that we can give feedback https://github.com/prisma/prisma-client-go/issues/539 and make the package better).

This is a kick in the pants for some of us.

I'd like to thank @steebchen for his patience and swiftness in responding to my queries and issues and the amount of effort he put in to this project. ❤️

[johnpena]

I find this to be a really strange and anti-strategic decision for the Prisma team to make.

I thought Prisma's brilliant innovation was that it allowed you to have a single schema (or set of schemas), from which you could: a. generate clients for every language you use b. have a multitude of services sharing a single database or a set of databases c. manage everything through a single interface and tool set (e.g. prisma migrate)

Such an innovation would solve problems I've had at every company I've ever worked for. Want to have two services written in different languages that use the same database? You can do that. Want to start writing things in language A and then port them to language B? You can do that too. Want to move a use case from service A to service B without having to rewrite everything? Basically zero effort.

The fact that the Prisma team is moving away from this work tells me they don't understand this enormous problem and the value that they were already providing in solving it. Instead of solving this problem (which is widespread, and for which I don't know of another existing equivalent solution) and leaning into it, the Prisma team seems to just be focusing on being a better node ORM than sequelize or knex or waterline or any of the already pretty good ORMs for node.

Definitely a head-scratcher.

[matthewmueller]

Hey @johnpena, thanks for your message, I think your interpretation is correct.

Prisma team seems to just be focusing on being a better node ORM than sequelize or knex or waterline

This is definitely our top goal for the next year or so. We want to be the obvious choice for an ORM in the Node.js ecosystem. We're not there yet. Reaching this milestone is required for everything else we do.

I thought Prisma's brilliant innovation was that it allowed you to have a single schema (or set of schemas)

I totally agree with you. As a Go and TS developer myself, being able to switch between the languages and apply the same concepts with the same schema is hugely useful.

This was seriously a tough call. But it boiled down to:

• We really need to focus on making the TS Client the best it can possibly be
• The Go Client wasn't a breakout success and requires effort and resources to make it so (@Southclaws mentioned videos, content marketing, etc.)

I'd also say I think we started this effort too early in our journey. After we become the defacto standard in the TS ecosystem, I do see us branching out to other languages again, more deliberately, with more resources. How that shapes up, remains to be seen.

[Southclaws]

Do you plan to provide resources for community clients in future? I'd love to look into contributing and buiding generators but there seems to be a lack of documentation for the query engine RPCs.

[stephenafamo]

I would like to recommend SQLBoiler as an alternative.

It generates type-safe models and query builders from your DB schema, and you can confidently regenerate the models whenever your DB schema changes.
This means you can continue to use Prisma's schema definition to manage your schema and migrations, and then generate your models from your updated DB.

Sadly, this does not really help those who are already using this client in production, migrating to any other tool would likely be a bit difficult, but for newer codebases, I believe SQLBoiler is a pretty great ORM with a similar philosophy that can fit well with other Prisma tools.

Disclaimer: I am one of the maintainers of SQLBoiler (although that is a recent development 😅)

[jjonsson]

I would like to recommend SQLBoiler as an alternative.

From SQLBoiler's documentation:

Table names and column names should use snake_case format.

• We require snake_case table names and column names. This is a recommended default in Postgres

This means we would need to change all our names to snake_case to use SQLBoiler, right?

[stephenafamo]

This means we would need to change all our names to snake_case to use SQLBoiler, right?

That is pretty old, and this is no longer true. I took some time to check this and it works just fine.

To be clear, postgres makes everything lowercase, so when getting the table names and column names from the DB to generate the schema, with postgres, the driver gets everything in lowercase which may cause the model attributes to look weird.
For example, Jets.PilotID will become models.Jet{Pilotid string}

[RobertCraigie]

This is very sad news, the Go Client was instrumental in the creation of my Python Client, it probably wouldn't even exist without the Go Client. I'd like to say a massive thank you to @steebchen 💚. I hope Prisma picks this back up in the future.

@Southclaws Do you plan to provide resources for community clients in future? I'd love to look into contributing and buiding generators but there seems to be a lack of documentation for the query engine RPCs

If anyone is interested in building generators I'd be more than happy to help and answer any questions.

For RPC reference these modules could be useful for anyone wanting to implement it themselves:

Generation RPC loop: https://github.com/RobertCraigie/prisma-client-py/blob/main/src/prisma/generator/generator.py#L80-L133

RPC interface: https://github.com/RobertCraigie/prisma-client-py/blob/main/src/prisma/generator/jsonrpc.py

[Raraku]

I just thought about how convenient it would be to use Prisma for golang and I got excited when I found out there was a client library. This is sad news ... tbh.

[Southclaws]

Looks like SQLBoiler is the tool to go for. It plays nicely with Prisma's existing schema management.

I was evaluating Ent and sqlc but both are tightly coupled to the schema and migration process. I'd prefer to keep using Prisma's schema and migration tools as they are excellent.

Because SQLBoiler reads from the DB in order to generate code, this makes it possible to work alongside Prisma. I think more tools should be built around this database-first paradigm of generating stuff (like declarative source-of-truth schemas or code) from the database itself!

So, my workflow might look like:

• Edit schema.prisma
• Run prisma migrate dev --skip-generate skip generating code
• Run sqlboiler generator from the newly migrated development DB
• Avoid writing dirty non-typesafe awkward SQL string literals for another week 🎉 💯 😁

[oSethoum]

For those who loved using Prisma Go, I suggest taking a look at the Entgo ORM which is by far the best and the fastest in my opinion at least.

[dfalgout]

Though I was looking forward to Go support becoming GA, I completely understand and appreciate your decision to keep focused on providing the best experience for TS first.

It is far better to become the de-facto for a narrow market before expanding. I appreciate the work the team at Prisma has done so far on all of their offerings. I am very happy that you have the sense to make these difficult decisions because it means that one day (maybe) we can have this in Go!!

GO TEAM PRISMA!

[Southclaws]

Playing with Ent as an option, annoyingly it's a full solution (its own schema and migration tooling) so I started a simple converter script: https://github.com/Southclaws/prisment

Feel free to try it out, contribute code, etc.

[seamory]

Prisma is the bestest orm of golang and i've always believed. Just hope prisma for golang will be back in future someday. Thanks to every developer and contributor.

[Frosty21]

I can understand where @matthewmueller is coming from and I appreciate the clarity and the transparent communication from the Prisma Team. Things come and go, but support with Go will come in time. As @dfalgout said keeping focused on the best for TS first with prisma is the logical decision even though it's a tough decision. I can empathize with @robin-macpherson on nexus-plugin-prisma support being dropped being similar to this but I think it was necessary and now the community can take it. For me using nexus-prisma is really smooth to use once you get past the JSDocs (still need work) but its low priority atm but its TS first so they'll hopefully keep support for that. Go will come back it's just a matter of time and demand

[ghost]

Is it still useable? (I see you do some gradual updates) I'm using both Node.js and Go and would love to see this project afloat...

[sejr]

Another person here who has been following the development of this for as long as I can remember. Was actually visiting this repository in the hope that it was finally stable.

Prisma was so close to becoming "the" data modeling language across not just my own personal projects, but at places I've worked. With this move, that is no longer feasible.

Thanks @steebchen for all of your hard work.

[Celso-Ricardo]

That's bad. I was starting to be encouraged to learn GoLang when I saw that The Great Prisma ORM had Support for Go. Hopefully Things will change in the future. Great Job Guys !

[denik1981]

I have a web app in TS and prisma and not playing to migrate to Golang, but when it counts to designing the CLI (terminal) I find better options in the Golang ecosystem. I would like to use my already defined prima schema to talk to the DB hence this project was extremely useful. I'm sad.

[Pherwerz]

what can we do to bring this project back

[johnoldham33]

I too would like for this to be supported again, prisma seems to be the de-facto ORM for TS/JS and it would be really nice to combine microservices written in go and TS using one schema definition and one client generator, would be incredible. Using sqlboiler for now

[denik1981]

s to be the de-facto ORM for TS/JS and it would be really nice to combine microservices written in go and TS using one schema definition and one client generator, would be incredibl

The current pool of ORM clients as alternatives to Prisma is quite low in the Go ecosystem.

[johnpena]

s to be the de-facto ORM for TS/JS and it would be really nice to combine microservices written in go and TS using one schema definition and one client generator, would be incredibl

The current pool of ORM clients as alternatives to Prisma is quite low in the Go ecosystem.

sqlboiler and ent are both largely at feature parity with prisma and (importantly) have maintainers committed to the long term success of the project.

[gurleensethi-docker]

This is unfortunate, I am pretty sure if you release a GA version it soon will become the db package of choice in Go community. 'Early Access' keeps a lot of devs and organizations off from using it.

[kaykhan]

Used prisma in my node.js/typescript projects, moving to golang project would have liked this. Someone has mentioned ent but i found the introspection tool (entimport) is not as mature as prisma's.

[gurleensethi-docker]

I would also add that in my recent analysis of past few months, there is slowly a shift happening in the industry where more and more individuals and teams are realizing that node is not the way to go for backend applications and considering jumping ship to languages like Go and Rust. For example, you can see a recent post from Facebook Engineering about adding Rust as a supported server side language.

So not only would a Go client make sense but a Rust client as well.

[jamesblackjr]

I currently use Prisma for Node projects but now Go has become an important part of our stack, we wanted to use this Prisma client, and maybe we will if it gets enough community support. If I had to choose between keeping Prisma and switching to Go or Rust over Node, certainly I may have to drop Prisma from the stack, which would be unfortunate because I love Prisma!

[Southclaws]

Ent is almost there with Versioned Migrations but the DX is still not as good as Prisma was.

[iansinnott]

Ent is also a very nice project but (to my knowledge) it doesn't have a db pull equivalent, which is very helpful for migrating to prisma if you have an existing database.

It would also be great to have a solution that works in both Node and Go (and others, ideally). Take prisma with you to whatever language you use.

That being said, i've had a good experience with ent and it's worth checking out for anyone who's turned off by the unmaintained status of this lib.

[s-takehana]

@matthewmueller Is there any update on this?

[Southclaws]

Ent is also a very nice project but (to my knowledge) it doesn't have a db pull equivalent, which is very helpful for migrating to prisma if you have an existing database.

It would also be great to have a solution that works in both Node and Go (and others, ideally). Take prisma with you to whatever language you use.

That being said, i've had a good experience with ent and it's worth checking out for anyone who's turned off by the unmaintained status of this lib.

They're not as good but there's primsment and entimport

[iansinnott]

They're not as good but there's primsment ...

Thanks @Southclaws. Hadn't seen these.

I actually started hacking on something similar the other day to do Prisma->Ent conversion. Even if prisma-go was maintained I think this might be preferable in certain cases, such as when you want to ship the whole thing to a user. You can do away with the prisma/engine and associated binary complexity.

Still hope prisma-go becomes a thing though.

[johnpena]

For those still looking for an alternative, we moved our production code from prisma-go to sqlboiler. By and large this was a seamless transition (leaving aside of course the fact that we had to rewrite a lot of code.) sqlboiler models are generated from your database schema, so we've continued to use prisma for schema management and migrations.

One thing I feel the need to mention is that our database read and write speeds have dramatically increased, likely due to removing prisma's serialization/deserialization step.

[Southclaws]

Honestly, there are so many layers to this problem I'd rather just have a new relational database that doesn't need some 1970s text-based language to transpile to and was code-gen type safe from the start 😂

[steebchen]

^ this 😂

[GuilhermeAmado]

Honestly, there are so many layers to this problem I'd rather just have a new relational database that doesn't need some 1970s text-based language to transpile to and was code-gen type safe from the start 😂

Something like SurrealDB?

[Southclaws]

Honestly, there are so many layers to this problem I'd rather just have a new relational database that doesn't need some 1970s text-based language to transpile to and was code-gen type safe from the start 😂

Something like SurrealDB?

Looks like this still uses an SQL-like query language, unless there's a more low level API hidden in their docs 👀

[und3fined]

Late 2022, I started use Prima (maybe it's late). I think, no any tools better Prisma. Anyway, thank you Prisma team.

[andyfleming]

Prisma having a first-class go toolset is a valuable proposition for adopters.

It provides a path for scaling projects that start in javascript/typescript but need to scale up parts/all of their API once they have stabilized. Leveraging a second, faster language, like go, gives them that escape hatch.

I hope to see this project picked back up.

[Southclaws]

It's frustrating I know but Prisma is a company with priorities. If they didn't make tough decisions like this, then the brilliant tooling Prisma have built may not exist! So while I think we're all disappointed that support has dropped so early into its lifecycle, we can be understanding that decisions must often be data-driven. I'm hoping Prisma make a return to Go once their business has scaled up a bit more and they have the capacity to commit resources to other markets. 🚀

[lukasholzer]

I think what's missing in this data chart is the number of developers that don't adopt Prisma because of a lacking go client that is officially supported/maintained