# Mautic DB Huge - Events & Import History - what can be deleted

**URL:** <https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336>\
**Category:** Product Support\
**Created:** [September 29, 2020, 4:03pm UTC](https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336 "2020-09-29T16:03:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikew](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/mikew/32/5156_2.png) [@mikew](https://forum.mautic.org/u/mikew)\
**Post date:** [September 29, 2020, 4:03pm UTC](https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336/1 "2020-09-29T16:03:37Z")

</div>

**Your software**  
My Mautic version is: 3.1  
My PHP version is: 7.2

**Your problem**  
My problem is:  
I have noticed that my DB is getting huge (okay we have over 1M contacts) but part of the problem is there are hourly imports coming into the DB and I see that both the lead\_event\_log and imports table are rather big.

Does anyone know if anything bad will happen if I purge the import table totally, and remove all entries from leads\_event\_log table where properties like “%file%”

---

<div class="post-metadata">

**Author:** ![mikew](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/mikew/32/5156_2.png) [@mikew](https://forum.mautic.org/u/mikew)\
**Post date:** [September 29, 2020, 4:36pm UTC](https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336/2 "2020-09-29T16:36:19Z")

</div>

This is what my DB is looking like:  
email\_stats | 16056.08 |  
| audit\_log | 3820.63 |  
| lead\_event\_log | 2837.56 |  
| campaign\_lead\_event\_log | 2698.25 |  
| leads | 1434.94 |

---

<div class="post-metadata">

**Author:** ![joeyk](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/joeyk/32/11164_2.png) [@joeyk](https://forum.mautic.org/u/joeyk)\
**Post date:** [October 2, 2020, 7:04pm UTC](https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336/3 "2020-10-02T19:04:11Z")

</div>

This is a very hard question. I have the answer, but you not gonna like it.

Will you need tracking data?

- If not, why to use Mautic?
- If yes you’ll need to scale this up.  
More info: [Login to Meetup | Meetup](https://www.meetup.com/Mautic-Meetup-Lagos/events/272511292/)

Or check this:

> [@Delete old rows from email\_stats table without breaking front-end](https://forum.mautic.org/t/delete-old-rows-from-email-stats-table-without-breaking-front-end/11201/3):
>
> Hi Ruth: Thanks so much for your reply. I’ve reviewed the issue as reported on GitHub. I think I’ll use the SQL Update statements as provided in that issue till hopefully a future release addresses the issue. I think any implementation of size makes it quite costly to run given the disk space requirements to handle how it presently grows the email\_stats table. I would imagine the [mautic.com](http://mautic.com) folks are experiencing some pain on this issue, ya? Thanks again! Bob H.

---

<div class="post-metadata">

**Author:** ![EJL](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/ejl/32/12155_2.png) [@EJL](https://forum.mautic.org/u/EJL)\
**Post date:** [October 2, 2020, 8:19pm UTC](https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336/4 "2020-10-02T20:19:27Z")

</div>

Is this causing space issues, or is this hindering your performance?

Reason I ask is there seems to be some relief on the way. (At least indirectly)

> <https://github.com/mautic/mautic/pull/7874#issuecomment-696208024>

---

<div class="post-metadata">

**Author:** ![mikew](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/mikew/32/5156_2.png) [@mikew](https://forum.mautic.org/u/mikew)\
**Post date:** [October 4, 2020, 5:56am UTC](https://forum.mautic.org/t/mautic-db-huge-events-import-history-what-can-be-deleted/16336/5 "2020-10-04T05:56:35Z")

</div>

Thanks @joeyk going to check those articles out.

We need tracking, but not for all the records and for so long back,

@EJL - it is performance related. going to check out your links as well.

Thanks to both above
