It's not just about overhead/performance. cgo-free means no need to set up a cross-compiler if targeting other devices. Just "go build" with the right GOARCH and GOOS will let you compile a binary that will run on most devices.
Static builds cannot have cgo too if I am not mistaken.
The following go flags let you build statically-linked cgo binaries, provided that all the C libraries that you're using support static linking and don't call the NSS functions in glibc:
-tags netgo,osusergo -linkmode external -extldflags -static
I regularly compile (cross-compile, even) static Go binaries that use the cgo sqlite package. But it's certainly a lot simpler if you can avoid cgo.
I'm pretty sure that C is a much better choice if you really care about binaries that run on most devices
Depends on what you mean by "most". The cross compile story for Go is far superior to C for the platforms it supports.
Absolutely not. Maybe runtime overheads are minimal, but builds are so much harder to do. And yes, you need to figure it out maybe once, but it is still a lot more effort than just pulling in a new dependency. Now repeat that same effort for every new application, vs pulling that into every new application.
that’s really not true when the database is all in memory, statements are prepared, and so on.
but the overheads also stack up, the database/sql api is fairly allocation heavy too unless you do a lot of work and that friction increases quite a bit with the ffi boundary.
this is not to suggest “modernc is faster” - it’s not for a lot a workloads.
there are opportunities for optimization all over both approaches.