It will be a performance issue at some point.  It creates a lot of allocator &amp; GC churn.<p>Part of the reason this is mitigated somewhat has to do with how the Beam VM manages GC.  It&#x27;s per process, which provides a few nice features.  One is that processes that do a lot of &quot;work&quot; tend not to be long-lived, and consequently they tend not to accrete a lot of heap allocations.  The share-nothing concurrency model enforces an isolation pattern on the developer, which then allows the GC to make some guaranteed assumptions about what is safe and isn&#x27;t safe to reap.  The combination of those to factors allows GC sweeps to be both typically small&#x2F;short and also done in parallel with other scheduled running processes, so that GC doesn&#x27;t block all the execution resources.<p>Considering the use case here though, I&#x27;d really not worry about it.  The only way it&#x27;d likely bite you is if you were building a <i>massive</i> scale email pushing application, and you were weirdly trying to optimize for using as low-end, or as few, machines as possible to run it, and you hadn&#x27;t already found yourself flagged by every mail relay as being a spammer.