I only tested it very quickly as part of a lightning talk. however after a quick search I was able to find someone who did do some benchmark testing: https://g

I only tested it very quickly as part of a lightning talk. however after a quick search I was able to find someone who did do some benchmark testing: https://github.com/jinzhu/gorm/issues/298#issuecomment-65747130 https://github.com/jinzhu/gorm/issues/298#issuecomment-65747... gorm didn't fare to well against the non-ORM options. The method in which ORM's use to well be ORM's in Go is called reflection. It's generally considered to be a performance hit and most devs I spoken to will try to avoid using it if possible.Exactly how big of a performance hit it is depends on the situation.IT performs more allocations than non-reflection code. So in the case of an ORM where you may be performing these actions in loop (a query that returns hundreds or thousands of results) that may be deeply nested (many relations, user that has posts that have images that have tags and so on) it could end up being a bottle neck. Additionally there was another detail that really turned me off from gorm. Consider the following code: user := User{} db := getGormDB() db.Delete(user) If you were to run that Go code, given an actual gorm DB connection, the gorm ORM would delete every row in the user table. EDIT: I just noticed those benchmarks are pretty old. It's very possible and probably quite likely things have improved since then.