Does KumoMTA support storing its spool in a remote database?
Hey there @hospitable-vespa, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.
The performance implications of that approach are significant, what is your use case?
I want to make my MTA cluster horizontally scalable on demand. I want to be able to decrease the number of KumoMTA instances without having to wait for their spool to go empty.
The performance hit is not worth it. Issue commands to send the existing spool messages to another node and then spin it down. You don’t have to wait for the spool to naturally drain.
Also what are your sending rates? A single node can handle a lot.
I want to be able to send up to 10k emails a second, but they would usually be sent in scheduled bursts. 99% of the time, those instances would be sending just password reset-like emails. I imagine we would have to keep the new instances to handle that traffic for about 4 hours, then we’d start scaling the cluster down back to just 1.
What setup would you recommend for this use case?
Where will you be hosting things?
And how are you handling this now?
We are planning a new project to send promotional emails initially. We’re considering using AWS ECS for this purpose. The cluster would share an IP address attached to a proxy, which still requires some warming up.
I don’t see how a new organization will go to sending 10k messages per second, that’s 36 million per hour. Dynamic scaling with k8s is very early optimization when you’re just starting out.
Thank you. I’m probably over-engineering this. I’ll go with the simpler one-instance solution.
A single instance can easily scale past 10m messages per hour, so you have a lot of runway.