A Magento database bloats because tables that log every cart, page view, and admin session are never pruned by default, so a store that runs for two years can carry tens of gigabytes of stale rows that slow every query, backup, and checkout. The fix is not exotic: enable quote cleanup, cut log retention, keep indexer changelogs small, and truncate a short list of report tables on a schedule.
This matters even on a fast Hyva frontend. Hyva speeds up what the browser renders, but the database sits behind every add-to-cart, order save, and admin grid load. When the quote table holds millions of abandoned carts, checkout queries crawl no matter how quick the storefront paints. This guide names the tables that grow, explains why, and gives the exact settings and commands to keep an Adobe Commerce or Magento Open Source database lean.
Why the database grows in the first place
Magento is built to record almost everything. Every shopper who adds an item creates a quote. Every product view can write a report row. Every admin login and every guest browsing session leaves a trail. None of that is wrong, it powers cart recovery, reports, and personalization, but Magento ships with cleanup either disabled or set to retention windows measured in months.
On a low-traffic store the growth is slow enough to ignore for years. On a mid-sized store, these tables can accumulate two to three million rows a month. The symptoms show up gradually: checkout feels slower, the admin order grid takes seconds to load, nightly backups stretch from three minutes to fifteen, and a database that should be a few gigabytes is suddenly 40 or 50. A 15 GB backup restores in roughly two to three minutes; a 50 GB one takes ten or more, which turns every deploy and every staging refresh into a wait.
Because Hyva keeps the frontend quick, teams often misread the slowdown as a server problem and throw hardware at it. More RAM masks a bloated database; it does not fix it. This is exactly the kind of foundation work that keeps a Magento and Adobe Commerce build healthy over its life, and it is cheaper than the CPU upgrade it gets mistaken for.
The tables that actually bloat
Not every large table is a problem, and not every problem table is obvious. These are the repeat offenders on Magento 2 and Adobe Commerce.
| Table group | What it stores | Why it grows | Safe cleanup |
|---|---|---|---|
quote, quote_item, quote_address |
Every cart, converted or not | Abandoned carts are never deleted by default | Enable sales_clean_quotes cron |
report_event, report_viewed_product_index, report_compared_product_index |
Product views, compares, reports | Written on browsing, rarely read | Truncate on a schedule if reports unused |
catalog_product_frontend_action |
Recently viewed / compared actions | One row per action, per visitor | Prune rows older than 30 to 90 days |
customer_visitor, customer_log |
Guest and customer session trails | One row per visit | Prune rows older than 30 days |
*_cl (indexer changelog) |
Pending index changes | Balloons when cron or consumers stall | Fix indexers, do not blind-truncate |
cron_schedule |
Scheduled task history | Every cron run leaves rows | Delete rows older than a few days |
adminnotification_inbox |
Admin notifications | Accumulates for years | Truncate freely |
magento_operation, async bulk tables |
Message queue / bulk operations | Grow with API and mass actions | Prune completed operations |
A healthy indexer changelog table holds a few hundred to a few thousand rows. If a *_cl table has millions, that is a signal, not just bloat: your indexers are failing or running too infrequently, and the changelog is the backlog. Truncating it hides the problem and can corrupt index state. Fix the root cause first, which we cover in Adobe Commerce cron and indexer health. GetPageSpeed’s guide to cleaning a huge Magento database is a good reference for the per-table detail.
Quote cleanup: the single highest-impact fix
The quote table is usually the worst offender because it grows with traffic, not with sales. Most carts are abandoned, and every one of them is a quote row plus item and address rows. On a busy store that is the majority of your database.
Magento ships a sales_clean_quotes cron job to delete expired quotes, but it is frequently disabled or set to keep quotes for far too long. Enable it and set a sane lifetime:
bin/magento config:set sales/clean_quotes/enabled 1
bin/magento config:set sales/clean_quotes/lifetime 30
A 30-day lifetime removes quotes older than 30 days that never became orders. If you run cart-recovery email flows, match the lifetime to your recovery window so you do not delete a quote your abandoned-cart sequence still needs, then let cleanup take everything past it. Seven to fourteen days suits stores with short recovery windows; 30 is a safe general default.
One caution: on a database that has never been cleaned, the first cleanup run can be enormous and lock tables. Do the initial purge in batches during a low-traffic window, then let the cron maintain it from there.
Log retention and report tables
Magento’s logging and reporting are the second big source of growth. customer_visitor alone “can accumulate gigabytes of data that nobody ever reads.” The defaults keep far more history than most merchants use.
Set log retention short. The historical default was 180 days; busy stores should drop to 7 to 14. Configure the schedule so cleanup runs daily in a quiet window (for example 03:00), and clean in batches of 10,000 to 20,000 rows so a single run never locks the table for long.
For the report_* tables, decide first whether you actually use Magento’s native reports. Many merchants pull analytics from GA4 or a BI tool and never open the built-in reports. If that is you, those tables are pure overhead and can be truncated on a schedule. If you do use native reports, prune by date rather than truncating wholesale.
cron_schedule is a quieter offender: every cron run leaves a row, and on a store with a dense crontab that is thousands of rows a day. Delete anything older than a couple of days.
Where this shows up, and where it does not
Database bloat has a specific performance signature, and knowing it saves you from fixing the wrong thing.
It slows the admin and checkout, not cached storefront pages. Category and product pages served from full page cache do not touch these tables, so PageSpeed on a Hyva storefront can look fine while the order grid and checkout drag. That mismatch is the tell. The admin never sits behind full page cache, which is why a bloated database is one of the top reasons a Magento backend feels slow, a problem we break down in speeding up the Magento admin.
It inflates every database-bound operation. Backups, staging refreshes, mysqldump, and any query that scans a bloated table all pay the tax. Server response time is capped by how fast the database answers, so uncontrolled growth quietly raises Time to First Byte over months, which we cover in reducing Magento Time to First Byte.
It does not fix a genuinely slow query, a missing index, or an undersized server. Cleanup removes dead weight; it does not tune what remains. Move sessions to Redis and search to OpenSearch, both parts of a well-chosen technology partner stack, so the database is not doing work it should never hold in the first place.
This is also a self-hosted concern. Merchants on fully hosted platforms like Shopify or BigCommerce never touch database maintenance because the platform owns it; self-hosted Magento and self-managed Shopware put it on your team. That is the trade for the control and extensibility those platforms give you, and it is why a maintenance plan matters.
A maintenance cadence that keeps it lean
The goal is prevention, not periodic firefighting. A store that cleans weekly never accumulates the 50 GB backup problem, while one that waits until queries crawl faces a risky, table-locking cleanup on a live database.
A practical cadence looks like this. Continuously: sales_clean_quotes enabled with a 30-day lifetime, log cleanup daily with 7 to 14 day retention, and indexers monitored so changelogs stay small. Weekly: prune cron_schedule, customer_visitor, and catalog_product_frontend_action by date, and truncate adminnotification_inbox and unused report_* tables. Monthly: review table sizes, confirm the crons ran, and check that no *_cl table is creeping up.
Everything here belongs in a real maintenance plan rather than an emergency ticket. We describe what that should cover in Magento support and upgrades, and it is the kind of ongoing care Hyva development engagements build in so the speed a migration buys does not erode as data piles up.
For the technical detail behind each table and archiving strategies at enterprise scale, the Magento 2 database maintenance and cleanup strategy and table partitioning and archiving write-ups are worth reading alongside your own audit.
FAQ
Is it safe to truncate the quote table directly?
Not on a live store without care. The cleaner path is to enable the sales_clean_quotes cron with a sensible lifetime so Magento removes only expired, unconverted quotes and leaves active carts alone. A blind TRUNCATE deletes in-progress carts and can break checkout for shoppers mid-session. If you must do a large first purge, run it in dated batches during a low-traffic window.
Which Magento table is usually the biggest?
On most stores it is the quote family (quote, quote_item, quote_address), because it grows with all traffic rather than just sales. Behind it are customer_visitor and the report_* tables. Check your own store with a query that lists tables by size before assuming, since a heavy catalog or a chatty integration can shift the ranking.
Why is my indexer changelog table millions of rows?
That is a symptom of indexers not running, not normal bloat. A healthy *_cl table holds hundreds to a few thousand rows. Millions mean cron or the indexer consumers have stalled and the changelog is a growing backlog. Fix the indexer health first; truncating the changelog to reclaim space can leave your indexes inconsistent.
Will cleaning the database speed up my storefront?
It speeds up the admin, checkout, and every database-bound query, and it lowers Time to First Byte over time. It will not change how fast a cached category or product page paints, because those are served from full page cache and never read the bloated tables. If your storefront pages are slow, that is a different fix.
How often should we run database maintenance?
Set the recurring crons (quote cleanup, log cleanup) to run continuously, prune the visitor and schedule tables weekly, and review table sizes monthly. Regular small cleanups are far safer and cheaper than one large cleanup on a database that has already grown out of control.
Bemeir keeps Magento and Adobe Commerce databases lean as part of ongoing support, so a fast Hyva storefront stays fast under real data growth. Learn more about our team, or start at Bemeir.
