PrestaShop Store Stuck? Practical Guide Between Pros

When a PrestaShop store becomes inaccessible due to a too-greedy statistics module, you need to act fast, without breaking everything. In this article, I share solutions I recommend between peers - neither sponsored nor commercial - simply effective and tested.

The Frequent Issue: Store or Back-Office Inaccessible

PrestaShop’s native statsdata module records a mass of data: visits, page views, connections, logs… But without maintenance, this data ends up saturating the MySQL database, causing:

• Severe slowdowns
• 500 or 504 errors
• Complete blockage of front-office and back-office

This scenario is common, especially on shared hosting or unsupervised stores.

First Emergency Intervention: Cleanup via phpMyAdmin

When you can no longer access the back-office, only one solution: intervene directly in the database.

Concrete Steps

1. Make a complete database backupVia phpMyAdmin > Export > SQL Format (always!)
2. Execute the following queries in the SQL tab:

<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_connections</span><span class="p">;</span>
<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_connections_page</span><span class="p">;</span>
<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_guest</span><span class="p">;</span>
<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_pagenotfound</span><span class="p">;</span>
<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_referrer</span><span class="p">;</span>
<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_referrer_cache</span><span class="p">;</span>
<span class="k">TRUNCATE</span> <span class="k">TABLE</span> <span class="n">ps_log</span><span class="p">;</span>

These tables are most prone to overflow if you use statsdata without regular cleanup. Once emptied, access is generally restored immediately.

Think about deleting or temporarily disabling the statsdata module to avoid recurrence.

Long-term Security: Recommended Automated Cleanup

Once calm returns, better to anticipate future overflows. I often recommend to my non-developer peers the following module:

Recommended Module: Automated Cleanup - PrestaToolbox

What it offers:

• Targeted and scheduled cleanup (guests, stats, logs, cache…)
• Simple interface, no technical jargon
• Scheduling via Cron task
• Clear explanation of each action

A real maintenance assistant, adapted to stores that want neither overload nor surprise.

Useful Statistics, Without Overload: Alternative to statsdata

What if we stopped inflating the database just for stats? I also recommend this reliable and lightweight alternative:

Recommended Module: Op’art Stat

Why I appreciate it:

• Uses native PrestaShop data
• No impact on performance
• Offers 80+ clear and useful reports (revenue, margins, carts…)
• Modern interface, adapted to non-tech managers

A good way to track your performance without exploding the database.

Summary: 3 Cases, 3 Answers Between Pros

Encountered Case Recommended Solution Inaccessible back-office Manual cleanup via phpMyAdmin (empty large tables) Regular maintenance to automate PrestaToolbox module: scheduled cleanup, secure actions Statistics without overload Op’art Stat module: advanced reports without overloading database ## Conclusion

You’re not alone in experiencing this kind of mishap. The important thing is to have the right reflexes and right tools:

• Access to phpMyAdmin for emergencies
• A reliable module to automate cleanup
• Optimized statistics to manage your store without weighing it down

As a PrestaShop developer for over 15 years, I recommend these solutions with confidence - because they save time, avoid scares and make management more serene.

Article published on August 7, 2025 by Nicolas Dabène - PHP & PrestaShop expert with 15+ years of experience