A Magento database grows in two ways: the catalog (healthy) and the operational residue - logs, quotes, visitor records, changelog tables - that never shrinks on its own (unhealthy). We regularly inherit stores where half the database is residue: backups slow down, queries creep up, and one day the disk fills during peak trading. Here is what grows, what to do about it, and what to configure so it stops growing.
The Tables That Grow Forever
The usual suspects, in rough order of growth rate on a busy store:
report_viewed_product_*,report_compared_product_*- analytics event logging, unboundedcustomer_visitor,customer_log- session trackingquoteandquote_item- abandoned carts, kept forever by default*_clchangelog tables - mview backlogs when cron or indexers failcron_schedule- a row per job per minute; grows fast, pruned by cron settingssales_*archive candidates - old orders are legitimately kept, but their growth needs planningemail_log,vault_payment_token, integration logs from modules - the long tail
Finding Your Bloat
SELECT table_name, ROUND(data_length/1024/1024/1024, 2) AS gb
FROM information_schema.tables
WHERE table_schema = 'magento'
ORDER BY data_length DESC LIMIT 20;
Run this first. The answer is often surprising - we have found 40GB in report_event-era tables on stores whose owners assumed the catalog was the size.
Safe Cleanup
Report tables: safe to truncate on most stores; verify nobody uses the built-in reports first (most merchants use external analytics).
Quotes: Magento 2.4+ has built-in abandoned quote cleanup (Stores > Configuration > Sales > Checkout > clean quotes older than N days). Enable it. For legacy stores, a dated-delete on quote where is_active = 1 and old - with foreign-key awareness, tested on staging.
cron_schedule: controlled in Stores > Configuration > Advanced > System > Cron - history retention settings. Default keeps success entries briefly and failures longer; verify it is actually pruning.
Changelogs (*_cl): never truncate while the corresponding mview is behind - you lose pending changes silently. Fix the indexer backlog first, reindex fully, then the cron prunes them naturally.
Prevention Over Cleanup
- Enable the built-in quote and log cleanups - they exist, they are off by default
- Watch retention on any module that logs (payment gateways, integrations); many default to forever
- Set alerting on database disk usage - 80 percent is the “fix this calmly” line, 95 percent is the “fix this tonight” line
The Maintenance Rhythm
Quarterly: the size query above, a review of the top tables, and confirmation that cleanup configs are still in effect (upgrades and migrations reset things). Pair it with your backup verification so the same window covers both.
Database bloat is the slow leak of Magento operations - invisible until it is expensive. The cleanup is an afternoon; the configuration to prevent recurrence is an hour. Both are cheaper than the emergency they prevent.