A large marketing database can be a huge burden with the tiered contact pricing of marketing automation platforms such as HubSpot, Pardot, or Marketo. The annual pricing for 100,000 contacts, even with Mautic Cloud, starts at no less than $15 to 25K per year. The open source, community edition of Mautic is an alternative that does not limit how many contacts you can store. However, because the open source edition of Mautic is self-hosted, you are solely responsible for provisioning a server (or servers) with enough capacity to store and process the number of contacts that you need.
Using a single server to host a large instance of Mautic may not necessarily be the best idea. Because Mautic uses a series of cron jobs to automate actions such as rebuilding contact segments and triggering campaign actions, an underpowered server can struggle under the load – leading to errors such as partially executed campaigns and unsent emails. As the leading Mautic consultant in the marketplace, we have built custom instances of Mautic for performance marketing customers using technologies incorporating load balancers, LXC/LXD containers, shared session storage with Redis, and master/slave or multi-master database setups.
Even if you regularly clean up the number of contacts in your Mautic database, your Mautic instance can struggle under the load if you use a single server to host it. If your website receives a large number of page hits, the Mautic tracking script (mtc.js) and embedded elements such as Mautic forms and dynamic web content can slow down the load times of your entire website. Slow page load times can lead to lower search engine rankings, as Google’s algorithm considers load time when determining the rank of a web page in its SERPs.
Mautic is pretty much the most cost-effective solution you can get if you have a large number of contacts. All of the subscription email/marketing automation services charge based on the number of the contacts you store, and emails you send per month. It isn’t uncommon to see marketing departments renewing one to three-year contracts with marketing automation vendors for five, or even six figures annually.
The investment to scale the open source version of Mautic for large-scale email marketing is up-front, but the operating cost thereafter is very affordable. If you are not technically inclined, you need the help of a developer or sysadmin to deploy Mautic at a large scale with good performance.
As mentioned above, some of the approaches that can be used to optimize Mautic for larger companies with sizeable marketing databases and email campaigns include:
External Load Balancing (HTTP/HTTPS) – A large Mautic deployment should not be hosted on a single server. It should be hosted on multiple servers running Apache or Nginx and PHP-FPM, behind a load balancer which can be managed by the cloud provider, or a custom load balancing solution such as HAProxy.
In a typical configuration, one of the Mautic backend servers is designated as the “lead instance” with cron jobs enabled. The “lead instance” batch processes segments and campaigns, while the other backends serve web requests that are generated by the Mautic tracking pixel and/or landing pages.
Shared Storage (for media) – A scalable Mautic deployment requires shared storage such as NFS (for a virtualized deployment) or a mounted volume from the host (for an LXC/LXD deployment).
Any Mautic instance has some data folders that need to be persisted, such as the media directory – containing images that are uploaded through the file manager in the visual builder. To preserve state, all of the Mautic nodes need to be able to access this data simultaneously.
Shared Storage (for PHP sessions) – A Redis key-value store should be set up to persist PHP sessions across multiple Mautic servers. This prevents users of the Mautic dashboard from encountering a “CSRF token error” when browsing through the different pages in the dashboard. Redis should be secured with authentication and/or an access control list because otherwise the session tokens can be compromised by attackers.
A poor man’s alternative to properly implementing session storage with Redis can include “session stickiness” at the load balancer level. This isn’t a perfect solution as marketing users will time out when their cookie expires, potentially causing them to lose unsaved work. If you set the cookie duration too high, then the load will not be roughly equally balanced between all of the available backends.
Multi-Master Database Servers – The Mautic application uses MySQL (or MariaDB) to store its users’ marketing databases. A multi-master database can improve the scaling of your database across multiple database nodes. Although each write needs to be mirrored over to the other master(s) increasing the latency on-write, multi-master significantly speeds up the read performance of Mautic with multiple database nodes. This leads to a more responsive dashboard, faster execution of campaigns, and speedier loading of embedded Mautic assets.
Internal Load Balancer (TCP) – An internal load balancer, separate from the aforementioned external load balancer, is required to balance the database queries across the multiple database nodes. MySQL clients (such as Mautic) use the TCP protocol to communicate with database servers over an internal network. Therefore, a load balancer such as HAProxy should be used to perform health checks on the database servers, and pass traffic accordingly. A limited privilege database user is set up for HAProxy so that it can tell whether a MySQL server is responding within the timeout threshold (i.e. healthy).
You can see that a considerable amount of effort is required to setup a Mautic instance to support a large number of contacts, monthly emails, and web traffic. If you are a marketing department struggling with the high costs of other SaaS services, contact our Mautic deployment team who can provide your company with the infrastructure you need to cost-effectively execute marketing automation programs to a large database of prospects and/or customers.
