I was testing a couple of Go ORMs about 7 months ago, to find which option could possibly be the best. Did not occur to me to document my experience with them during that time, so these notes are a vague recollection and may not be true anymore. Also did not test each ORM for a long time, so the following is the summary of first impressions.
First ORM i tested. Everything seemed great until i tried to create an endpoint with nested queries. Wasted two days trying to fix that bug. Documentation didn't help. Stack overflow didn't help. So this is a no from me. Also at the time there were some performance problems. Don't know if they changed, so double check that.
Pretty good option. As stated in the documentation , it provides a set of extensions on top of the excellent built-in database/sql package. Feels very vanilla, everything is written by hand. newsbyside.com uses it to query the articles. For small projects, this seems like a great option. Once the projects and database schemas start to grow, keeping everything in sync could become problematic.
Used it while creating an example go fiber server. Seems like the ORM has potential. Documentation was good. The syntax felt a bit weird, but that's probably a personal thing.
I was quite skeptical on codegen tools for a bit, but this one did get me. This mostly solves the problem of keeping the database schemas and queries in sync with each other. So this is my favorite package. It's really great. It's so great that i wanted to write a tool that also could generate something. So i wrote gomakeme for fun ( with optional SQLC support )
The basic gist of SQLC is = create a model_name.sql file that can hold both the database schema and the queries for the table and run SQLC to generate valid + typesafe functions that run the sql queries and return the data.
One negative of this is that postgres is not supported on windows, but that can be easily fixed by downloading WSL and installing the binaries that are linked in the documentation.
While picking the best option, there is the question of how transferable the learned skills are. The presented packages can be split into two groups:
Or in short, to ORM or not to ORM? Both methods have their ups and downs.
As i have observed there is some kind of law of specificity, at least when it comes to programming and asking questions, which could be summarized as:
The more specific the question, the harder it is to find a correct answer to it.
For example, if you have a scenario where you want to find answer for a problem that deals with
finding the correct answer for the first option will be 20x easier than the second option. This is because there are at least 20x more people that know how the vanilla version works. And most probably a variation of your question has already been asked before, so all you have to do is formulate it correctly. This also means that if you pick the most vanilla version (like writing plain SQL queries to get the information from the db), your ceiling to dealing with difficult queries is extremely high.
One additional thing to consider is the transferability of knowledge. It's a lot better to learn a thing once, rather than to learn the abstraction of the same thing 20 times.
If you pick plain SQL for querying the data, you only have to learn it once. Any other additional SQL knowledge will only increase your skill level. If you change the backend language, your sql knowledge has a transferrability of 100%.
If you pick an ORM, you're dependent on it. If you want to switch the backend language, you also have to learn and then use a new ORM. I wouldn't say that there is 0 transferability in between ORMs ( understanding how one works will help you understand how the next one works ), but in general, i would guess that there are deminishing returns on how much new stuff you learn after your 3rd ORM.
There are ORM tools that potentially provide more value than writing plain SQL queries by hand. While writing some small projects for learning Node, i used Prisma, and it was pretty good. Automatic migrations, good documentation and examples. But if you migrate from Node to Go, then you're dependent on Prisma, which can be problematic at times.