Careful. We (Tailscale) tried to use static Go binaries a year or two ago built with Zig (zig cc) and the SQLite performance was atrocious. It passed all our tests but it didn't survive deploying to prod. It was a very quick (and uneventful) rollback at least.
(Needless to say, we have better load testing tooling now)
I forget the details, but something about the libc allocator used by SQLite-with-Zig-libc being ... not good.
It's well-known that musl is in general much, much slower than glibc. People keep rediscovering that for some reason, likely because they hear of stuff like old echoes of Usenet posts ranting against glob "bloat", not being aware that a lot of what people call bloat is specialization of a lot of performance-sensitive algorithms to leverage SIMD, special-casing, math optimisations, etc.
When you check the glibc mailing lists, it's obvious performance is a predominant concern.
I’ve experienced the same performance issues with cgo + a library compiled with zig cc. IIRC it seemed like an issue with the zig tooling not plumbing the optimization flags through the ancient autotools build system for our required dependency. After a while fiddling, we just rolled it back too.
I haven’t tried this in about a year, so maybe the tooling doesn’t have these issues now.
(Needless to say, we have better load testing tooling now)
I forget the details, but something about the libc allocator used by SQLite-with-Zig-libc being ... not good.