Have you ever felt that existing Go ORMs are either overly complex or don’t give you enough control? What kind of ORM would better fit your real-world development needs?
In my experience, many Go ORMs tend to lean too far toward heavy abstraction, which can make things harder to understand and customize. Because of that, I decided to create my own tool called Margo. It still relies on code generation, but focuses on being clear, straightforward, and predictable. Early benchmarks show strong performance, and I’ve already started using it in production across several projects. It’s been refreshing not having to hand-write SQL, map structs manually, or debug missing fields. I’d really appreciate any feedback, especially ideas for features or improvements you’d like to see next.
I have used ORM outside Go and found that this is a good way to complicate things. An extra layer. As one developer said:
ORM can make life easier for simple queries and harder for more complex queries.
And I have found that CTE is to me a way to make complicated queries simpler. And no ORM I know supports CTE. ORM may support 80 percent of all queries. More complex queries you have to write outside ORM as pure SQL.
So why master 2 “languages” (ORM + SQL) when you can only master one even better (SQL)?
To be fair, you can use that as an argument to use an ORM for simple queries and hand-code all other SQL. Which is what I do on some projects I inherited with GORM for example. For simple CRUD operations, GORM is fine. Anything involving even a simple join, I hand-code the SQL.
I agree with this. People will argue that you can use an ORM and then just swap out MySQL for Postgres on the back-end with reckless abandon and that has never been the case in any substantial project I’ve worked on.