| For our website builder (https://pinkpigeon.co.uk) we once chose an ORM (GORM for Go specifically). In case you don't know what this does, it's an abstraction layer for working with databases like MySQL, PostgresQL, etc. Everyone warns against using them, but in the very early days of my learning Go, there was a tutorial that included this, so I just went with it. ORMs give you some advantages: Switching database drivers (aka, switching databases) is pretty easy. If it's supported by your ORM, you can then just switch to a different DB entirely.
For the simplest of operations, like just writing stuff to your DB and then retrieving it again, they work a charm. Especially in Go, the ability to automatically marshal things into structs is a blessing. BUT, then you try to start doing things with many2many relationships, or retrieving sorted data in a very specific, nested query and things go sideways quickly. I ended up finding it much harder to try to figure out how to do some pretty obvious things. Endless hours on Stackoverflow fighting the ORM and its shockingly bad documentation... Eventually I just bit the bullet and learned how to write Postgres queries, along with a small Go library called sqlx (https://jmoiron.github.io/sqlx/) which massively outperformed GORM (https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq...) and it's much more straight forward to reason about the relationship between my application layer and the DB. |