How are you measuring memory storage size? Are you sure you are looking as resident memory size and not just the virtual memory size?

Actual storage of the structures should be nothing. Interfaces are "fat pointers" but that should really just be an extra word which node would have at least that if not more.

My guess is that if you are looking at virtual memory that more memory/garbage is produced in PARSING and not storing and that the virtual memory size allocated is high even after garbage collection but RSS should be different.

Interesting observation! The most simple explanation would be that it is memory claimed by the Go runtime during parsing of the incoming bson from Mongo. You can try calling runtime.GC() 3 times after ingest and see if it changes your memory. Go does not free memory to the OS immediately, but this should do it.

2 other options, a bit more speculative:

Go maps have been known to have a bit of overhead in particular for small maps. Even when calling make() with the correct capacity. That doesn't fit well with the memory profile you posted well, as I didn't see any map container memory in there...

More probable might be that map keys are duplicated. So if you have 100 maps with the key "hello" you have 100 copies of the string "hello" in memory. Ideally all 100 maps qould share the same string instance. This often happens when parsing data from an incoming stream. You can either try to manually dedup the stringa, see if the mongo driver has the option, or use the new 'unique' package in Go 1.23

heap dump from pprof