Database Maintenance with Self-Hosted Mailcoach

Bob Murdoch • July 11, 2024

mailcoach

In my experience if you're running Mailcoach on cheaper hardware, it will work well until your database gets into the low millions of counts for email sends. At that point, I've found some of the queries that run when sending campaigns to slow down substantially. While there may be additional indexing that's possible to help address this, the simple solution for me was to archive some old database records.

To my knowledge, Mailcoach doesn't offer a solution to automate this, but it's simple enough to handle with a Laravel console command run on a schedule.

I chose to create a second database, set up that connection in my app/config/database.php file and copy rows older than a certain time frame from the Mailcoach database to the archive database.

Since schema may change over major releases, I chose to make my backup tables just have a primary key field and a json field, so I could json_encode the entire row I'm copying over without worrying about fields or how they may change over time.

You can of course just delete the rows older than a certain age.

I chose to automate archiving the sends, clicks and opens table. Assuming you use tags for click/open tracking, you'll want to take a look at the tags unique to the removed campaigns that have null foreign keys after the other changes occur. You can archive or remove those as well, and if you want to put them back together with their foreign keys just be sure to make a plan for that prior to moving anything.

If you're completing this task with MySQL and your tables have grown quite large, you may want to take a look at this Stackoverflow thread for info on how to free up space claimed by the database afterwards. If you're on 8.x there are simpler commands outlined in the replies that will do the trick compared to 5.7x and below.