Containers provide os level virtualization, so the overhead is minimal, and is mostly in management overhead and resources needed to run the whole contraption.
Generally, for go software, containerization provides almost no benefits – perhaps, it simplifies deployment a bit, but that’s it. go software is already self-contained, so resource isolation aspects of docker – the big chunk of why it exists – does not help anything.
What remains are various virtual networking solutions – that arguably do more harm than good – see all the struggle enabled TCP Fast Open on docker managed virtual bridges for example, and a fancy scheduler and updater – it’s easy to download, update, and schedule execution of the container.
Docker (which is also written in go btw) grew to become an a massive monster that can do way more than storagendoe requires (swarms, clusters, volumes, fancy networking) and all this reduces reliability and increases use of resources.
So, if you want efficiency – run storagenode directly on your host OS. There are no dependencies, so no conflicts with existing software (aka dependency hell). You will need to manually configure systemd to start your node, and run stroagenode-updater to keep it updated.
It’s a non-zero amount of work.
Here is where podman comes in. It’s a drop-in replacement for docker (you can literally symlink docker command to podman and all your docker commands will continue working) but it’s much more lightweight that actual docker, it does not have a separate service that is always running, it can run containers rootless arguably easier than docker, and it generates service definitions for systemd automatically for you.