Mautic performance with millions of contacts

General Discussion
, ,
1

Hi Mautic community,

I’m evaluating Mautic for a client with a specific use case and would appreciate your expertise before committing to
this architecture.

Context:

  • Client manages approximately 5,000 sending domains for many brands and locations (bookshops)
  • Each domain has its own contact list (ranging from a few hundred to tens of thousands of contacts)
  • Total contacts across all domains: several million
  • Each domain needs to send campaigns independently

Why we’re considering Mautic:

We’ve already tested major commercial solutions, but hit significant limitations:

  • UI not designed for managing thousands of separate lists/audiences
  • API rate limits that slow down automation
  • Lack of flexibility for our multi-domain workflow

This is why we’re now exploring self-hosted Mautic as a potential solution.

My concerns:

  1. Segments scalability - If we create one segment per domain (5,000 segments), how will mautic:segments:update perform? What’s the practical limit before experiencing timeouts or performance degradation?
  2. UI/UX - Is the admin interface usable with thousands of segments in dropdown menus?
  3. Database impact - How does the lead_lists_leads table scale with millions of segment memberships?
  4. Cron job duration - What’s a reasonable segment rebuild time we should expect? At what point does it become unmanageable?

Alternative approaches I’m considering:

  • Multi-tenant setup (multiple Mautic instances)

Questions:

  1. Has anyone successfully run Mautic with 1,000+ active segments?
  2. What’s the recommended architecture for this multi-domain scenario?
  3. Are there plugins or configurations that help with large-scale segment management?
  4. Would you recommend a different approach entirely?

Any feedback from those who have scaled Mautic to similar volumes would be greatly appreciated.

Thanks in advance!

2

Hello @pgaliegue,

I have worked with Mautic instances handling millions of leads, and scaling to that level requires careful planning. A few key recommendations:

Organization and access control:

  • Use ID-based naming conventions for segments/campaigns/emails (not just descriptive text) - this becomes critical at scale.
  • Implement strict role-based access control. Not everyone needs access to everything.
  • Document your architecture thoroughly from day one!

Technical considerations

  • Segment updates become increasingly time-intensive as you scale. You’ll need robust server specs and likely custom optimization scripts.
  • Database maintenance is crucial, regular optimization and cache clearing strategies are essential!
  • For email delivery at this volume, I would strongly recommend Amazon SES.
  • Mautic updates can become very time consuming, specially when you dealing as well with 3rd party plugins. Never change Mautic core files!

Mautic is likely your best option for cost-effectiveness at +100k contacts. Commercial platforms become prohibitively expensive at this scale. I have written a detailed HubSpot vs Mautic comparison that might help you justify the approach to your client.

That said, this is a complex project that requires an experienced team!
Good luck :folded_hands:

3 Likes
3

Thanks for sharing, much appreciated!

1 Like
4

Hello @pgaliegue,

Segments scalability - If we create one segment per domain (5,000 segments), how will mautic:segments:update perform? What’s the practical limit before experiencing timeouts or performance degradation?

You need to handle segment updates one by one. Then they are not linked and no impact on each other. If one crashes, the others are still updating. It is also easier to manage ressources and load.
We manage segments update for our 700+ customers this way and it performs with 1000+ segment.

UI/UX - Is the admin interface usable with thousands of segments in dropdown menus?

I believe it depends of the server resources you have, but this works with our 1000+ segments customers.

Database impact - How does the lead_lists_leads table scale with millions of segment memberships?

This is again a server performance question. We have a big DB servers (physical mysql servers with duo master/slave) and with several millions of rows in the table, no issue.

Cron job duration - What’s a reasonable segment rebuild time we should expect? At what point does it become unmanageable?

With what I explained on point 1, we have set 20min segments update.

What is important to keep in mind is that you need to setup something scalable. On our hand, campaigns update, commands trigger, email generation, email sending, etc. all of this is set with queues and autoscaling resources.

I’m glad to talk with you about you project if you think we could help.

1 Like