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

[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 #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 😅)

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

[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

[AriaFantom]

I hope this project get started officially maintained it will be very easy to convert languages and sync between them

[sarmad4444]

It's been a whole year and I'm very glad to see the features and adoption prisma(JS) got over this year. There are now thousands of tutorial videos and articles, a well-established community and QAs. I think now (after a complete year), the prisma team should reconsider their decision and continue work on go client. This will be an amazing gift for new year.

[stephenafamo]

Here to suggest Bob as an alternative.

Bob has a first-class Prisma driver which will use your existing schema.prisma file to generate an ORM and Factory.

There is a known issue caused by the prisma CLI not passing @map and @db attributes on columns. See Issue 3998. However, if the community finds it useful, I plan to support the Prisma schema as closely as possible, writing a custom parser if necessary.

GitHub Link: https://github.com/stephenafamo/bob
Website: https://bob.stephenafamo.com/docs

[eliliam]

Wow, I am actually shocked that Prisma would drop Go support entirely, right during the biggest growth phase of the entire Prisma project. This is a huge blow to the usability of Prisma in enterprise applications, especially ones that are shifting away from JavaScript due to performance and maintainability issues. Golang has huge adoption in enterprise environments, but is somewhat lacking in personal projects, which I feel is where the Prisma team is looking at specifically in this decision.

Please reconsider this decision, and at least provide a minimal client for Go, even if it may be somewhat lacking compared to the JS/TS client.

[bulenttokuzlu]

Well, I am pretty sad to hear that. Golang is for enterprises, not for home developers, looking for fancy interface tools.
We are a company developing services for enterprises, and we use java, go, nodejs, javascript, vuejs, flutter, k8s, etc.... etc.....
Golang is the by far the best utilized, best performing, stingy for resources, container friendly, easy to develop language we are using.

[merlindru]

Please reconsider this.

On that note, I still see commits by @steebchen keeping things up to date. (Thank you!!)

Why not make it official? 😉

[steebchen]

Hello everyone, it's @steebchen, the main maintainer of the Go client.

I've been considering resuming work on the project, especially because of the recent activity. I truly believe that the Go client is a valuable tool that many people would appreciate, as the Go ecosystem currently lacks a robust database client and tooling at this time. Prisma seems to effectively fill this gap.

If anyone is interested in advancing the Go ecosystem by reviving the Go client, ensuring its maintenance, and enhancing it with new features, I would be sincerely grateful if you could consider supporting me through a sponsorship. Maintaining and expanding the Go client requires a significant amount of effort. The next big goal would be to release a production-ready version and market it as such.

I have some plans in mind for the Go client, but to dedicate more time to it than just a few hours a month, a sponsorship would be a wonderful option. By choosing a higher sponsorship tier, you would also receive the added benefits of prioritizing your issues as well as personal assistance from me, whether for you individually or for your company. I can provide help with setting it up, as well as consultation on any Go client, database, infrastructure, or CI/CD related matters.

If you're interested in supporting the development of the Go client, please consider sponsoring me via GitHub sponsors, or contact me to discuss. Your support would be greatly appreciated.

[vasiliyb]

@steebchen lets remove the deprecation notice, love to see the Go client getting attention!

[steebchen]

The Prisma Client Go repository was transferred to me now (big thank you, @janpio and @prisma!), so it lives at https://github.com/steebchen/prisma-client-go from now on, and is now officially maintained again by me.

---> Read the full announcement: Prisma Client Go: Resurrection <---

Read the quick start on the new docs page: Quickstart

If you already have a Prisma project, read the upgrade manual.

I'd also like to thank Alexander Belanger and Bryan Onel at https://www.oneleet.com for being the first bronze sponsor, as they are already using the Go client. If you like these news, let your employer know that the Go client is revived, and if they ask, send them my sponsor profile 😀

See --> #860 for more!

[steebchen]

Thank you @Oneleet, @f-tepel and @osilkin98 for sponsoring! ❤️