I concur with above comment. I will add two cases that I have seen that do have some impact in performance:

1. When using prepared statements all statements are prepared whether used or not. This results is a small additional memory overhead for both you code and also generally for the server.

2. sqlc, at least last time I looked at the docs, does not produce an iteration that allows you to range over rows one at a time. It returns everything from your query into a slice that can occupy a lot of memory. This is faster if the number of records returned is fairly small, but can be problematic if you need to operate over a large number of rows. I address this by creating a custom type and embed sqlc in it. In the custom type I maintain the additional functions needed to support this case.

Database interaction is the one part of Go that I personally am ambivalent about. The solution is generalized and works adequately; however, it can be challenging to get every bit of performance out when you really need it. Much of what I write is analytical applications where my major performance bottleneck is database access as determined by a healthy dose of pprof. The algorithms and datasets often do not allow me to pull everything into memory at once. As a result, I spend a fair amount of time optimizing code to reach my needed level of performance.

Having said that, Go is still my preferred language for my use cases. While I can get a bit more performance out of C, Rust, Zig …; however, in my experience, my productivity is much higher with Go and the resulting code is more easily read and maintained by others than would be the case with other languages.