Your PrestaShop database keeps growing: which tables you can empty and which you cannot

The database backup takes longer and longer, the hosting provider warns that you are nearing the space limit and some back office screen is slow. You look at what is taking up so much room and discover it is neither the products nor the orders: it is tables with names like connections, guest or log, with millions of rows nobody has ever looked at.

Let us look at which tables grow on their own, what they are for and what can be cleaned without losing anything important.

First, measure

Before deleting anything, get the list of tables sorted by size. phpMyAdmin or your hosting's database tool shows it directly; you can also query information_schema.TABLES, filtering by your database name and sorting by DATA_LENGTH + INDEX_LENGTH. Almost always, a handful of tables account for most of the space.

The examples use the ps_ prefix, which is the default; yours may be different.

Those that grow with every visit

ps_connections and ps_connections_source

They record every visit to the store and where the visitor came from. PrestaShop's internal statistics use them (visitors, traffic sources). With bot traffic, they grow very quickly.

Can they be cleaned? Yes, the old rows, if you do not use the internal visit statistics or a recent period is enough for you. You will lose the visit history of those statistics modules, not orders or customers.

ps_guest

One record per visitor identified by a cookie, with technical browser data. It is linked to connections and to carts.

Can it be cleaned? Carefully: only guests not associated with any customer or with any cart that has an order. Deleting guests indiscriminately leaves broken references.

ps_pagenotfound, ps_statssearch and similar

Pages not found and searches made in the internal search engine, if you have the corresponding statistics modules enabled. They are useful for spotting broken links and understanding what your customers are looking for, but rows from years ago rarely are.

Can they be cleaned? Yes, the old ones. If it is of interest, export a summary of the most frequent searches first.

Carts

ps_cart and ps_cart_product store every cart ever created, including those that never became an order. In a store that has been running for years, there are hundreds of thousands.

• Carts with an order are never touched. The order points to its cart, and many screens, invoices and modules need it.
• Recent carts without an order are not touched either: they belong to customers who are shopping now or who may come back, and they are the ones abandoned cart recovery modules use.
• Very old carts without an order can be deleted, along with their lines. First check that no module uses them as a reference (associated cart rules, saved carts, quotes).

Logs

ps_log

This is the log you see in Advanced Parameters → Logs. The core and the modules feed it. A module that writes a message on every visit can fill it in weeks.

Can it be cleaned? Yes, the back office has an option to empty it. But first look at what is filling it: if a message is repeated thousands of times, there is something to fix, and emptying the table only hides the symptom.

ps_mail

The log of sent emails, if you have email logging enabled. Useful for checking whether an email went out, but it contains customer addresses.

Can it be cleaned? Yes, and it is advisable to do so with a defined retention period. Keeping indefinitely which emails were sent to whom adds nothing and is one more piece of personal data.

Module tables

Many modules have their own logs: API calls, synchronisations, notifications. Some purge them automatically and others do not. Review large tables with a module prefix and each module's configuration before deleting by hand.

What is not touched

It is also best not to touch:

• Customers and addresses, except through a data erasure procedure at the data subject's request, which must respect whatever you are legally required to keep.
• Expired specific prices and cart rules without first checking whether any is used as a template or whether a module depends on them.
• Configuration tables with values you do not recognise: they usually belong to uninstalled modules, but sometimes they belong to active modules with unclear names.

If the problem is the orders

Sometimes the big table is the orders table, and that makes sense: a store with years of activity builds up a lot of them. In that case it is not about deleting but about archiving: moving old orders out of the active tables so that the back office works with fewer rows, while keeping them complete and recoverable.

How to do the clean-up

1. Full backup of the database, verified.
2. Test the clean-up queries on a copy of the store and check that everything still works: orders, customer carts, statistics.
3. Delete in batches, not millions of rows in a single query, which can lock the table and the store.
4. Optimise the tables after deleting a lot, to recover the disk space.
5. Fix the cause: disable statistics you do not use, slow down the bots that generate thousands of connections, fix the module that fills the log.
6. Schedule the clean-up so that a big clean-up is not needed again in a few years.

How to solve it in PrestaShop

RKR Order Archive moves out of the active tables the orders older than the number of days you set (180 by default), in the statuses you choose, and stores them complete in archive tables: lines, history, invoices, payments, returns, credit slips, cart and messages. It has a simulation mode to see how many orders and rows it would move without touching anything, a cron with token, an email report, exact restoration with the same order number, and permanent deletion locked by default. It does not archive the order holding the latest invoice, delivery slip or order number, so that PrestaShop does not repeat the numbering. For the other tables (connections, guests, carts, logs), with a Rekire support hours package we measure your database, prepare the clean-up on a copy and leave it scheduled.